Guidance on FreeAndNil for Delphi noob

[Rollo62 550]

Thanks, its clear then, how the capture of anonymous methods work.
We came from the question how FreeAndNil might be helpful here, in this kind of situations, right?
Aren't there any situations where FAN can be useful, perhaps with an Assigned( FVar ) guard, were everybody can agree on?

 

I can see much use of FAN in Delphi RTL, Spring4D and all many places all around, but at the same time everybody disagrees on its usefulness & better to avoid it,
thats strange ...

Where and why is it useful then, if not in situations where I want to check and mark the validity of a lazy Field or the like, for example by Assigned()?
I cannot think of much use-cases, where I would ever need this.

- If I use it in the case where I inject an object to a class, not by DI, but by method or property, then this would make sense to protect a Field by FAN, IMHO.

- In a use case where I purely manage a Field myself by Create/Destroy, it doesn't make much sense if there is no possibility of delayed access to it.

 

So maybe somebody has a clean example, to show where it makes sense?

 

[Brandon Staggs 337]

18 minutes ago, Rollo62 said:

So maybe somebody has a clean example, to show where it makes sense?

If the variable is going out of scope, it doesn't make sense to nil it. If the variable is not going out of scope, then nil it.

 

I guess the question you might ask is why you would have a reference stay in scope after it is freed. That will depend on what is being done. For example, I do this if I have a lazy-loaded class field exposed as a property that is initialized in is getter. If there is something that invalidates the reference, it needs to be nilled so that it will not be freed again when the class is freed (double-freed), and so that it can be re-initialized the next time the property is read.

[Remy Lebeau 1505]

Sorry, I'm a little late to seeing this...

7 hours ago, Rollo62 said:

Yes, but from my experience, this helps to REDUCE the risk of AV's, in case of async processes, where you cannot safely cancel such async operation, because its not directly under your control.

I see it the other way - it can INCREASE the likelihood of an AV (or worse!).

 

The callback's Self pointer will be pointing at memory which the now-dead TMyClass object was occupying. It's undefined behavior for the callback to access that memory for ANY reason, period.  But let's forget that for a moment.

 

You nil the FMyVar member when freeing the TMyClass object, with the expectation that you can still access FMyVar later (which you can't).  If the memory that FMyVar was occupying  gets reused and overwritten before the callback is invoked, that memory might not be zeroed out anymore from the earlier nil.  And if it is not, then Assigned(FMyVar) will return True instead of False (if it doesn't just crash outright), and then you will try to call FMyVar.Add(...) and crash... or worse corrupt random memory trying to write to memory that it doesn't own.