In our previous episode, Sven Barth said: (as sb purely interested from an academic viewpoint, I have no real need for this)
> - a reference counted class (and its child classes) would include a > reference count field that the compiler knows how to access (for > automatic reference counting) and which can be accessed through RTTI > (for manual reference counting); it is *not* exposed as a regular field > as this might lead to identifier conflicts Does this mean multiple roots? That would make creating helpers for the refcounting different (since the field would be at a different offset everwhere) > - only *variables* (or parameters) that have a reference counted class > as its type will be subject to ARC; in extension this means that > assignments from/to a variable of a not reference counted base class > (e.g. TObject) will *not* change the reference count. Take this code for > example: One of the performance sinks with refcounting is passing parameters through a call chain. (e.g. a class calling an inner class in a field to do the actual work, inherited() etc). How do you think to tackle that? With const? Maybe that can > This will most likely result in "CreateObject" returning an instance to > class that is already freed (because the only reference inside > "CreateObject" is a (hypothetical) temporary of type "TARCObject" which > goes out of scope once "CreateObject" returns) It seems to me that implementation details of the return value handling (hidden/pseudo temp var etc) now trickle into the ARC design. Wouldn't it be more logical to make the result temp var a bit special so that it is not released when returned (requiring a func(); // ignores return value to pop the result and decrease the refcount? _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel