No difference; but FreeAndNil is better sometimes- makes sure that obj becomes Nil and you won't reuse it.Big difference, see my remarks above...
Thaddy, you've only given references to one point of view.Well, Allen Bauer is the author - both the routine and the blog post -. :o I rest my plea.
2594 matches!But NOT in the Delphi RTL sources. Incompetence is not an art.
But NOT in the Delphi RTL sources. Incompetence is not an art.I realized that incompetence is just your opinion.
Of those 2594 hits, maybe, just maybe, 94 are relevant.
1. FreeAndNil is basically and mostly a stop gap for sloppy programming: Use after Free..
FreeAndNil itself isn’t the culprit here.
FreeAndNil is basically and mostly a stop gap for sloppy programming: Use after Free.. But there are some - but rare - scenario's that warrant it.
I have to say that "features" that _hide_ bugs in program are not "desirable" features. I think the programmer would be better off getting an access violation which would hopefully cause him/her to fix the error.FreeAndNil is basically and mostly a stop gap for sloppy programming: Use after Free.. But there are some - but rare - scenario's that warrant it.
On a similar token, one might argue that even Free() can be seen as another helper that promotes sloppy programming.
The actual class destructor is Destroy(), not Free(). The only difference between them is that Free() checks for nil before then calling Destroy(). But most of the time, in code that manages its pointers correctly, a pointer will not be nil when Free() is called on it
I think the programmer would be better off getting an access violation which would hopefully cause him/her to fix the error.FreeAndNil brings it closer. Without zeroing, the error can be hidden for a long time.
I basically agree with what you stated above. What I find sloppy is that when a class is Destroy()-ed, the pointer (apparently) isn't set to nil, nor when it is simply freed. It has to be FreeAndNil.I think the programmer would be better off getting an access violation which would hopefully cause him/her to fix the error.FreeAndNil brings it closer. Without zeroing, the error can be hidden for a long time.
I think the programmer would be better off getting an access violation which would hopefully cause him/her to fix the error.FreeAndNil brings it closer. Without zeroing, the error can be hidden for a long time.
I have a more generally question: Do we have to Free or FreeAndNil every global Object we have created in the app before
closing it ?
I think he means is it enough just to Free or is it better to FreeAndNil?For local (not used twice) variable, or used only inside class/unit (rarely) - Free is sufficient.