[fpc-devel] Suggestion: reference counted objects

Chriss Kalogeropoulos iz.iznogood at gmail.com
Sat Sep 20 15:24:30 CEST 2014


Hello all,

IMO the best way to implement this is by controlling the TObject behaviour
through a compiler switch, something like "enable globally", "disable
globally", "enable for specific class" and in the latter case another
switch should mark the class that should have this behaviour enabled.

This should allow the compiler to emit different code per case.

But the question is what should be the behaviour for genetics and also how
should it work for packages (when and if they are implemented).
Also should this reference count be shared for interfaced classes or not?

Chriss
Στις 20 Σεπ 2014 3:26 μ.μ., ο χρήστης "Michael Van Canneyt" <
michael at freepascal.org> έγραψε:

>
>
> On Sat, 20 Sep 2014, Sven Barth wrote:
>
>  On 20.09.2014 13:11, Peter Popov wrote:
>>
>>> Please do not reference count TObject. This is a uniquely bad and
>>> unnecessary idea. I will switch to ANSI C if you guys do it
>>>
>>
>> Please enlighten me why you think it is bad.
>>
>
> Simple:
>
> For one, it will slow down your code.
> There will be lots of incr/decr of reference counts, just as for
> ansistrings.
>
> Secondly, there is lots of code that stores objects in lists of pointers
> and vice versa.
> Checking such existing code for side effects by the sudden introduction of
> TObject may take ages.
>
> So reference counting TObject by default is IMHO out of the question.
>
> I am not against a reference counted class (the idea exists since ages).
> But the solution is IMHO to invent a new attribute or whatever, to allow
> people to make an arbitrary class (and it's descendents) reference counted.
>
> Michael.
> _______________________________________________
> fpc-devel maillist  -  fpc-devel at lists.freepascal.org
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20140920/3d0ba4a8/attachment.html>


More information about the fpc-devel mailing list