After reading http://bugs.freepascal.org/view.php?id=19238 i wondered what's the reason to FreeThenNil procedure found in LCLProc.

What's the advantage over SysUtils FreeAndNil ?

procedure FreeThenNil(var obj);
begin
   if Pointer(obj)  nil then
   begin
     TObject(obj).Free;
     Pointer(obj) := nil;
   end;
end;
     procedure FreeAndNil(var obj);
       var
         temp: tobject;
       begin
         temp:=tobject(obj);
         pointer(obj):=nil;
         temp.free;
       end;

Luiz

Luiz Americo Pereira Camara wrote

After reading http://bugs.freepascal.org/view.php?id=19238 i wondered what's the reason to FreeThenNil procedure found in LCLProc. What's the advantage over SysUtils FreeAndNil ?

That's a hack to work around the fact that some destructors may access the object being destroyed via the given pointer instead of directly.

Can you explain this ?

Because to my understanding the code does exactly the same.

Michael.

No, these two procedures perform assignment and destruction in a different order -- even their names reflect that.

BTW, I think the check in FreeThenNil is redundant and should be removed.

Sadly, it does, although I do not think it is a good programming practice. See my first mail in this thread ;-)

Yes, I have seen that, but why is this relevant ?

I mean, if one does

   FreeAndNil(MyObject);

It really doesn't matter whether the reference MyObject is set to nil before or after the call to Free ?

Michael.

My collega explained to me what you meant (your original statement was not clear to me).

You're referring to cases like:

Var
   MyForm : TMyForm
destructor TMyForm.Destroy;
begin
   MyForm.Something;
end;

and then somewhere

   FreeAndNil(MyForm);

Which is simply wrong coding in the destructor.

I don't think you should provide for this. This is encouraging people to write bad code. They should get an error, and correct their code.

Michael.

I don't think you should provide for this. This is encouraging people to write bad code. They should get an error, and correct their code.

Agree.
I also don't understand why it is needed to manually free and set nil an object pointer if a destructor for the object exists which should do all this. This is like writing another destructor and makes object oriented programming (even more) useless.

On 15-1-2005 I had a heavy discussion with Mattias about this. IMO it was needed for a design flaw and he couldn't convince me why it was needed. I won't start that discussion again.

Marc

J?rgen Hestermann wrote

I also don't understand why it is needed to manually free and set nil an object pointer if a destructor for the object exists which should do all this. This is like writing another destructor and makes object oriented programming (even more) useless.

No, the destructor can not change the object pointer. That is the whole point.

2011/4/27 :

Which is simply wrong coding in the destructor. I don't think you should provide for this. This is encouraging people to write bad code. They should get an error, and correct their code.

Well, I have already said this is not a good practice, haven't I? But, it is not that easy to fix -- the calls are usually separated by many levels of nesting, including the message loop.

2011/4/27 Alexander Klenin :

No, the destructor can not change the object pointer. That is the whole point.

It does not even know which or how many variables are pointing to it, does it? If this is the case then what does it matter which ones of them are set to nil before or after it is freed?

In FreeAndNil it is first freeing the object while the there still exists a reference to it (temp). But the object does not know about temp or var obj anyways and has no reference to any of them (where should it have leaned about them in the first place?), or does it?

So IMHO this pocedure is essentially doing exactly the same as the FreeThenNil procedure. At least that is how I understand it.

I would like to see a non-trivial example of this.

Even if you can produce one (which I doubt), it doesn't change the fact that it is wrong coding.

Michael.

2011/4/27 :

+1
That is just bad coding. Fix the problem at the source, in stead of simply offering bandaids to encourage the developer to continue such bad practices.

I would like to see a non-trivial example of this. Even if you can produce one (which I doubt), it doesn't change the fact that it is wrong coding.

http://bugs.freepascal.org/view.php?id=16035

But what does this have to do with the problem you mention in FreeAndNil ?

It's rebuilding a component tree, while part of the tree is still being destroyed. That this will go wrong seems logical to me, but irrelevant to FreeAndNil.

Michael.

As you can see from the linked discussion,
currently implemented workaround involves FreeAndNil. I can imagine a similar bug which might require FreeThenNil instead.

I didn't see any linked discussion in the indicated page.

All I can conclude from this page is that there is a bug in TAChart, most likely returning children in GetChildren, which are in fact no longer there. But that is just guesswork, and still I fail to see the link with FreeAndNil.

If I see things in mails like like
"This code is so complicated, I can not understand what is going on." Then I automatically think "Badly written code" and therefore 'error-prone'.

But never mind.

Michael.

If you scroll down a bit, you will see a single note, pointing to http://lists.lazarus.freepascal.org/pipermail/lazarus/2010-April/051023.html

If I see things in mails like like "This code is so complicated, I can not understand what is going on." Then I automatically think "Badly written code" and therefore 'error-prone'.

I agree and even I tried to refactor it -- but my work was rejected by core developers.

I saw that, where do you think I got the quote from ? :-)

Ah? Strange. Maybe they wanted to promote FreeThenNil ;-)

Michael.

FreeAndNil(). I have written a crap load of components in my time, including composite components, and never had a problem with freeing children or subcomponents. You just need to do it in the right order, and obviously not reference something that is already free'd.

regards,
Graeme

That is quite possible, but neither me nor Martin was unable to find it. I'd appreciate any specific insight if you have it.

Did you run the code with valgrind or using a heaptrc unit compiled with -dFPC_HEAPTRC_EXTRA?

Alexander Klenin hat am 27. April 2011 um 18:46 geschrieben:

FreeThenNil is useful for variables like 'Application', which destructor triggers complex things and/or when the variable is used at a lot of places. During the destruction Application is still valid, so that all components can shut down cleanly. For example they can unregister their handlers. ?
But FreeThenNil is more limited than FreeAndNil. For example?you can not use it with multithreading, because of the small step between freeing the memory and setting the variable to nil.
?
?
Mattias
?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110427/51a770ae/attachment-0001.html>