I suggest leaving TList from FPC RTL as is. It works with pointers, so leave it be.
For refcounted objects we would use generic list like TFPGList from fgl unit. However, currently existing TFPGList implementation would be unable to deal with refcounted objects correctly because TFPGLists uses TFPSList (u can examine source file if interested), and TFPSList moves items like memory blocks. So TFPGList can not store refcounted objects just like it can not store interface vars. A generic class capable of storing interfaces and refc-objects correctly will need to use dynamic arrays under the hood because with dynamic arrays you don't loose type information 29.10.2014, 18:10, "Michael Schnell" <mschn...@lumino.de>: > On 10/29/2014 03:56 PM, hinsta...@yandex.ru wrote: >> Whatever; I disagree >> refcounted descendants of non-refcounted objects should be assignable to >> any variable of parent type; just like any variable is assignable to a >> variable of parent type > > And what about TLIst ? If TList is done for not ref-counted objects you > loose the ref counting when storing and retrieving them or you simply > don't know whet you get out. If TList is done for ref-counted objects, > you need an appropriate conversion when storing, as you might pull them > to a ref-counted variable.. > > -Michael > _______________________________________________ > 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
