Yes, I'm going to bring this up because the codebase I'm working on PROVES MY FRIGGIN' POINT! (Sorry for yelling....)
Yes, I'm going to bring this up because the codebase I'm working on PROVES MY FRIGGIN' POINT! (Sorry for yelling....)
Okay -- the programmer who wrote this stuff uses FreeAndNil all over. And as a result, I have to thoroughly investigate each one to figure out why. Is it because they were just duped by the FreeAndNillers? Or is there actually a reason for the pointer to be set to nil?
Sometimes there is a reason, and sometimes there isn't. But I have to check every single time.
Great.
Fire away, I don't care. ;-)
Okay -- the programmer who wrote this stuff uses FreeAndNil all over. And as a result, I have to thoroughly investigate each one to figure out why. Is it because they were just duped by the FreeAndNillers? Or is there actually a reason for the pointer to be set to nil?
Sometimes there is a reason, and sometimes there isn't. But I have to check every single time.
Great.
Fire away, I don't care. ;-)
It is a matter of preference.
ReplyDelete/flogdeadhorse
Well, I ALWAYS use FAN. For a very simple reason - it makes the code crash if I make a mistake and try to access the freed resource when I shouldn't have.
ReplyDeleteLars --
ReplyDeleteLOL -- sorry, I had to get it off my chest.
Well, I hope you FreeAndNillers at least have pity for the people that have to maintain your code. ;-)
ReplyDeleteI clean up my kitchen after lunch. For the same reason I clean up my pointers when I am done with them. Pointers pointing to something where they shouldnt point to are pointless.
ReplyDeleteNick Hodges I don't see why FAN would make it hard to maintain any code.
ReplyDeleteMy typical allocation pattern (and I think it covers about 99.99% of my code) is
obj := TSomething.Create;
try
...
finally FreeAndNil(obj); end;
It will always be like this. There are no hidden meanings. It's just a way that helps the machine tell me that there's something wrong with my code if I make a mistake.
Primož Gabrijelčič that's very true and useful indeed.
ReplyDeleteI use FreeAndNil, but only when I actually have to nil, otherwise I stick with Free. I can't say I really have an issue with it...
ReplyDeletePrimož Gabrijelčič If that were all that this code did, then there wouldn't be a problem. ;-)
ReplyDeleteI'm not quite consistent in how I use FreeAndNil, but generally speaking - if it is a property field, I FreeAndNil - if it is a local variable, I don't.
ReplyDeleteOn the other hand - if all variables were reference counted, assigning a nil would eventually mean a free.
I also use FreeAnNil within my destructors.
ReplyDeleteI only use FreeAndNil when I have to as well. But I never have to. ;-)
ReplyDeleteFor those of you wanting a trip down memory lane:
ReplyDeletehttp://www.nickhodges.com/post/Using-FreeAndNil.aspx
I almost never use FreeAndNil :) If something will fail it fails anyway!
ReplyDeletetry/except? ;)
ReplyDeleteAs mentioned above, in these cases I .Free - but if FGooglePlusComment is a field accessed through a property getter, I FreeAndNil.
I guess it is a result of passing a lot of objects around between threads, and preferring things to go out immediate with a nil bang, instead of the chance that a dangling reference may work for a while.
ReplyDeleteIt seems you can call members of destroyed objects as long as the memory is reasonably intact. We found out after upgrading from EurekaLog 6 to EurekaLog 7, which has protection to catch such fun.
ReplyDeleteI use FreeAndNil because it's painful enough to have to release yourself the usual objects in the XXIst century
ReplyDelete..chuckles @ Olivier..
ReplyDeleteOne bad thing in FreeAndNil - it first make pointer nil, and after that calls Free. It should be called NilAndFree :)
ReplyDeleteLars Fosdal Indeed, that's why I tend to use it. Unless I forget, which is too frequent... old habbits die hard. I also tend to use it on local variables, as it's easier to catch when something goes wrong then. Wouldn't be an issue if Delphi had RAII but...
ReplyDeleteI had to lookup FreeAndNil in the documentation to understand what all the fuss is about because I've never used it. :-)
ReplyDeleteKenneth -- you are a wise and insightful developer. ;-)
ReplyDelete