[fpc-devel] Suggestion: reference counted objects

[Marco van de Voort]

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?