On 29/10/2014 13:03, Sven Barth wrote:
On 28.10.2014 09:57, Hans-Peter Diettrich wrote:
Sven Barth schrieb:
Take unit Typinfo for example where quite some methods take a TObject
instance.
The TypInfo methods can determine the exact type of their arguments, and
act inside accordingly.
If you have a method X that takes a TObject parameter how do you plan
to pass it a reference counted object when these and TObject are not
compatible *at compiletime*?
It would be possible, if you had a special type
TAnyObject (can be ref or none ref-counted)
or a modifier "TObject ref_compatible"
TObject (not refcounted by default)
TRefObject = class(TObject); refcounted;
The compiler only needs refcounted code, for TRefObject and TAnyObject
, but not for TObject
TObject would need virtual methods for Inc- and DerRefcount (but this is
memory only once per class, not per object).
For TObject they do nothing, for TRefObject they do what the name says.
TObject only needs them if it is passed to TAnyObject, otherwise the
compiler does not generate calls to it.
In order for TAnyObject to work, TObject and TRefObject need the same
memory layout. But the memory for refcount can be allocated in front of
the object (as it is done for strings too). Then TRefObjects hidden
pointer, points to the same fields as TObject.
Memory (de-)allocation is done in CreateInstance/FreeInstance, which are
both virtual, and can account for the "refcount memory header"
In this case, the only overhead for none refcounted classes, are 2
entries in the VMT of each class.
If the Inc- and DerRefcount are not overidden by usercode, then WPO (or
class final ?) can optimize the code, and de-virtualize them for all but
TAnyObject.
Just my 2 cents.
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
