Marco and JT wrote a nice article for Dr. Dobbs. Good to see Delphi there.
Marco and JT wrote a nice article for Dr. Dobbs. Good to see Delphi there.
http://www.drdobbs.com/mobile/reference-counting-and-object-harvesting/240155664?pgno=1
http://www.drdobbs.com/mobile/reference-counting-and-object-harvesting/240155664?pgno=1
I haven't read Dr.Dobbs in years. Is it all web now?
ReplyDeleteYep, it was one of the last print mags for developers to go all web. Still has a certain cache, however.
ReplyDeleteWell, it was an interesting article. Not sure I understand why ARC is particularly useful on mobile, though.
ReplyDeleteIMHO introducing a new method for disposing is a kludge, Free is the method that should be doing it for backward compatibility, there is no issue arising from doing so, while there are issues arising from introducing a different pattern for immediate release.
ReplyDeleteAnd ARC isn't specific to mobile, Python is using it, DWScript has been doing it, and in the case of DWS, Free is disposing the instance, this is what ensures maximum compatibility, non-ARC-aware code then runs as it used to under the ARC scheme.
I agree ARC is not for mobile only. It might show up in other versions of Delphi in the future.
ReplyDeleteI disagree on freeing objects. Free and Dispose have two separate meanings and setting a reference to nil (not Disposing it) is what matches existing Delphi Free statement. Disposing on ARC should be a rare event.
Marco Cantù Free in Delphi is an immediate release, its only relationship to nil is that if it gets a nil, it does nothing. Otherwise it's doing what Dispose is doing, ie. an immediate call to the destructor, regardless of other references to the instances that could exist.
ReplyDeleteOn ARC, Free should be a rare requirement in the first place, and Dispose is redundant. But if code is to be backward compatible, Free should be an immediate release, like it has always been, or you'll have side-effects for all classes that are related to external resources (sockets, file handles, db handles, etc.) which have a high likelihood of having multiple references active at once (and thus nil'ing a reference won't equate a release in NextGen, hence side-effect compared to current Delphi). Those side effects may or may not matter, but they'll exist.
The only rationale for equating Free to setting a reference to nil (which does NOT match the existing Delphi Free statement in any form or fashion, FreeAndNil is closer, but that would still be a stretch), would be as a kind of (premature?) optimization, and would need to go along "try finally" exception frame removal to avoid redundancy with the implicit exception frame for ARC.
Equating Free to nil will only be equivalent to current Delphi if the refcount is one, and the Free is at the very end of a procedure or destructor, or followed only by other calls to Free. That's not a corner case, but that's at best a "common" situation.
The goal is to fully embrace ARC, using weak references and other techniques, not sticking with the traditional Delphi approach. In general, if you references around (even for resources) you don't want to free them if there are other references to the object. That's why Free wasn't mapped to disposing. I fully agree Free has basically no place on ARC, it is there mostly for compatibility with existing code.
ReplyDeleteMarco Cantù Well, when you explicitly call Free in current Delphi, you do want the instance destroyed, even if there are other references around (which there will be, in graphs, trees, linked list, notifications lists, event handlers, etc.).
ReplyDeleteFor compatibility with existing code, leaving Free untouched would have worked just fine, and you could have kept and used the Disposed flag to report double-frees and similar issues, which would have brought benefits to code with cross-version compatibility. Then later, introduce an hint/warning/deprecation for usages of Free, to eliminate it completely once NextGen cross-platform has advanced enough (without ever renaming Free as DisposeOf, and redesigning TComponent so you don't need a Free or DisposeOf).
Eric Grange 's suggestion sounds more than reasonable, IMO.
ReplyDelete