Hi Sven, Can you comment on how are you going to handle the case of TInterfacedObject and descendants? Are you going to use the same Addref & Release method ? How can you guarantee that the same counter will be updated in case of IUnknown implementations that introduce their own refcount variable (possibly with different name)?
Are you going to check that the class is already destroyed (because the arc has killed the instance) on IInterface.Release so that we should not get access violations on scenarios that mix ref counted classes and interfaces ? Thanks for your time and efforts, Chriss Στις 25 Σεπ 2014 4:14 μ.μ., ο χρήστης "Sven Barth" < pascaldra...@googlemail.com> έγραψε: > Am 25.09.2014 11:59 schrieb "Michael Schnell" <mschn...@lumino.de>: > > > > On 09/22/2014 08:37 PM, Boian Mitov wrote: > >> > >> Honestly if you don’t know what you are doing when using ARC, I doubt a > bit, you really know what you are doing otherwise either ;-) . > > > > Ref counted strings are no problem with any (normal) use of same. > > > > In this thread you find an example describing how ARC Objects easily can > impose memory leaks. > > Not really. The object instances themselves won't create memory leaks, > because with strings you don't get them either. The only problems are > typical "not threadsafe" problems of the classes themselves and there ARC > won't help you anyway as this is the programmer's job to ensure. > ARC objects will only be destroyed when the last reference to them has > gone out of scope. If there is still a reference, then there's still the > object. > > Regards, > Sven > > _______________________________________________ > 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
