<p>I believe you overcomplicate it<br /><br />Variable type should define if variable is reference-counted or not.<br /><br />class refcounted => refcounted<br />class descendant from class refcounted => refcounted<br />normal class => not refcounted<br /><br />pass refcounted instance as TObject => not refcounted at all...<br /><br />Consider existing COM interface implementation. Variable of interface type is a pointer. <br />Consider having var face: IUnknown;<br />then you pass it as pointer:<br />hash := CalculateHash(Pointer(face));<br />this should work correctly<br /><br />All functions which do not store pointers will work correctly with interface variables as pointers</p><p>All functions which do not store TObject will work correctly with refcounted descendant of TObject</p><p>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.</p><p>Same is true for refcounted objects: if you store them in good old TObjectList, it will hold invalid pointers.</p><p>However this all is just something to keep in mind. I don't see the need of overcomplicating it on compiler level.</p><p>Interface variable is a pointer.</p><p>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<br /><br /><br />29.10.2014, 16:48, "Martin Frb" <<a href="mailto:lazarus@mfriebe.de">lazarus@mfriebe.de</a>>:</p><blockquote>šOn 29/10/2014 13:03, Sven Barth wrote:<br /><blockquote>ššOn 28.10.2014 09:57, Hans-Peter Diettrich wrote:<br /><blockquote>ššSven Barth schrieb:<br /><blockquote>ššTake unit Typinfo for example where quite some methods take a TObject<br />ššinstance.</blockquote>ššThe TypInfo methods can determine the exact type of their arguments, and<br />ššact inside accordingly.</blockquote>ššIf you have a method X that takes a TObject parameter how do you plan<br />ššto pass it a reference counted object when these and TObject are not<br />ššcompatible *at compiletime*?</blockquote>šIt would be possible, if you had a special type<br />šTAnyObject (can be ref or none ref-counted)<br />šor a modifier "TObject ref_compatible"<br /><br />šTObject š(not refcounted by default)<br />šTRefObject = class(TObject); refcounted;<br /><br />šThe compiler only needs refcounted code, for TRefObject šand TAnyObject<br />š, but not for TObject<br /><br />šTObject would need virtual methods for Inc- and DerRefcount (but this is<br />šmemory only once per class, not per object).<br />šFor TObject they do nothing, for TRefObject šthey do what the name says.<br /><br />šTObject only needs them if it is passed to šTAnyObject, otherwise the<br />šcompiler does not generate calls to it.<br /><br />šIn order for TAnyObject što work, TObject and TRefObject šneed the same<br />šmemory layout. But the memory for refcount can be allocated in front of<br />šthe object (as it is done for strings too). Then TRefObjects hidden<br />špointer, points to the same fields as TObject.<br />šMemory (de-)allocation is done in CreateInstance/FreeInstance, which are<br />šboth virtual, and can account for the "refcount memory header"<br /><br />šIn this case, the only overhead for none refcounted classes, are 2<br />šentries in the VMT of each class.<br /><br />šIf the Inc- and DerRefcount are not overidden by usercode, then WPO (or<br />šclass final ?) can optimize the code, and de-virtualize them for all but<br />šTAnyObject.<br /><br />šJust my 2 cents.<br /><br />š_______________________________________________<br />šfpc-devel maillist š- š<a href="mailto:fpc-devel@lists.freepascal.org">fpc-devel@lists.freepascal.org</a><br />š<a href="http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel">http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel</a></blockquote>