[fpc-devel] Proof of Concept ARC implementation

Sven Barth pascaldragon at googlemail.com
Wed Oct 29 16:30:43 CET 2014


On 29.10.2014 14:23, Jonas Maebe wrote:
>
> On 27 Oct 2014, at 19:59, Sven Barth wrote:
>
>> Florian has written me an idea two weeks ago regarding the "backwards
>> compatibility" aspect (I won't argue the performance impact one ;) ):
>> - TObject and all descendants are reference counted (please no size
>> and performance discussion here)
>> - in code that does not use ARC ("modeswitch arc off" - the default;
>> or maybe better a local directive) all instance variables are
>> considered "weak"
>> - constructors of code that does not use ARC return with reference
>> count = 1, otherwise reference count is initially 0 (like for
>> interfaces and currently in my branch)
>> - destructors also take care of this additional "pseudo" reference
>> upon being called; thus the object is freed after the last ARC
>> reference is gone AND (for legacy code) Free/Destroy has been called
>> (thus when the reference count really reaches 0)
>>
>> With this approach there would be no change for legacy code (except
>> for the additional refcount field per instance), as reference counting
>> would only happen with enabled ARC directive/modeswitch (thus there
>> could still be memory leaks for such classes). New code could take ARC
>> into account and could be written accordingly with "weak" modifiers, etc.
>
> There's still the problem if you create an instance in ARC code, then
> pass it as a (e.g. const) parameter to a routine from a unit that does
> not use ARC and which stores it in a linked list or a local field, and
> later the instance goes out of scope in the ARC code (so it gets freed)...

Hmm... yes, that would indeed be a problem.

> Apple also supports mixing ARC and non-ARC code in Objective-C, but the
> only way this works is by requiring the programmer to manually perform
> the reference counting in non-ARC code. I don't think there's any quick
> hack possible that allows you to mix them transparently without a lot of
> pitfalls.

We can of course also provide means to manually do reference counting 
(will e.g. be necessary for TStringList if one has code that abuses 
Objects[]...). Nevertheless if one mixes refcounting and non-refcounting 
code with care (maybe we can add optional warnings/hints when passing 
instances between ARC and non-ARC code) it should work.

Regards.
Sven



More information about the fpc-devel mailing list