I believe you overcomplicate it
Variable type should define if variable is reference-counted or not.
class refcounted => refcounted
class descendant from class refcounted => refcounted
normal class => not refcounted
pass refcounted instance as TObject => not refcounted at all...
Consider existing COM interface implementation. Variable of interface type is a pointer.
Consider having var face: IUnknown;
then you pass it as pointer:
hash := CalculateHash(Pointer(face));
this should work correctly
All functions which do not store pointers will work correctly with interface variables as pointers
All functions which do not store TObject will work correctly with refcounted descendant of TObject
With lists it's worse. If you store pointers to interface variables, they become invalid the moment you don't have any "managed" variables left in scope.
Same is true for refcounted objects: if you store them in good old TObjectList, it will hold invalid pointers.
However this all is just something to keep in mind. I don't see the need of overcomplicating it on compiler level.
Interface variable is a pointer.
Reference-counted object IS TObject. TObject IS pointer. Reference-counted object IS pointer. These should be compatible. If some programmer stores refcounted object as TObject, then his refcounted variable goes out of scope, and then he wonders why he gets Access Violation, it should be his problem of not understanding how stuff works
29.10.2014, 16:48, "Martin Frb" <laza...@mfriebe.de>:
On 29/10/2014 13:03, Sven Barth wrote:On 28.10.2014 09:57, Hans-Peter Diettrich wrote:It would be possible, if you had a special typeSven Barth schrieb:If you have a method X that takes a TObject parameter how do you planTake unit Typinfo for example where quite some methods take a TObjectThe TypInfo methods can determine the exact type of their arguments, and
instance.
act inside accordingly.
to pass it a reference counted object when these and TObject are not
compatible *at compiletime*?
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
_______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
