[fpc-devel] Suggestion: reference counted objects

Marco van de Voort marcov at stack.nl
Sun Sep 21 15:09:01 CEST 2014


In our previous episode, Sven Barth said:
> No, not multiple roots. If a class is declared as refcounted (and it's 
> parent class is not) then a hidden field is inserted into its list of 
> fields, just as a normal one would, only that it isn't accesible using 
> the "."-operator (because it won't have a valid Pascal identifier). The 
> compiler of course knows the offset at compile time and at runtime the 
> field can be accessed using the class' RTTI which would have a 
> "RefCountOffset" field added (if that offset is < 0 then the object does 
> not support reference counting).

So in summary: the compiler must pass the fieldoffset to the runtime helper,
instead of having one refcounted root with known offset.

> Did anyone till now really complain about the performance impact of 
> reference counting on interfaces? Especially since they are used *so* 
> much in today's OOP designs?

I never really benchmarked it. I never use interfaces in my own abstract
data structure designs, mostly because the existing classes don't, and I
don't like the refcount. (since i usually also need to access the classes as
normal instances)

I did benchmark interfaces in combination with variants as part of a decal
evaluation.  That was, euh, painful.
 
> 
> function Test: TObject;
> begin
>    Result := (TTestClass.Create as IInterface) as TTestClass;
> end;

Hmm. This looks like a (Delphi) faq item to me, how to convert interface back to a
class. Usually the answer is IComponentreference (or what it is called), if
this is legal, I wonder why it didn't come up before.
 



More information about the fpc-devel mailing list