[fpc-devel] Proof of Concept ARC implementation

[Jonas Maebe]

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)...

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.


Jonas