[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