Re: ARC and Manual Memory Management
Re: ARC and Manual Memory Management
- Subject: Re: ARC and Manual Memory Management
- From: Greg Parker <email@hidden>
- Date: Mon, 10 Aug 2015 12:42:08 -0700
> On Aug 10, 2015, at 12:12 PM, Dave <email@hidden> wrote:
>
>> On 10 Aug 2015, at 19:11, Uli Kusterer <email@hidden> wrote:
>>
>>> On 10 Aug 2015, at 13:59, Dave <email@hidden> wrote:
>>>
>>> Has anyone come up with a way of having the source code support both ARC and Manual Memory Management without using #IFDEF or #IF ?
>>>
>>> I’ve never understood why the compiler doesn’t just ignore code like:
>>>
>>> [super dealloc];
>>>
>>> [MyObj release];
>>>
>>> If it’s being compiled for ARC, that way both could be compiled with the same source code or is there more to it?
>>
>> Because then there'd be no point in using ARC. ARC is supposed to take the hassle of manual memory management off your hands, and automate it to avoid mistakes. It is also less misleading if the retain/release lines aren't in your code, compared to having them in there but being no-ops. It also inter-operates seamlessly with non-ARC code (as it generates the retains and releases for you, it is equivalent to manually managed code to any non-ARC caller).
>
> If it just ignored those constructs, it was be much less confusing, simply because there would only one set of source code. release or dealloc are not guaranteed to do what is says on the tin anyway, I mean you can override them and do whatever you want. I can’t see that ignoring or just having empty methods under ARC would make it more confusing, especially if the compiler emitted a warning.
One problem is that it is very easy for either the ARC version or the non-ARC version to go unused and become incorrect after subsequent changes. For example, the code might look like it supports non-ARC but the retain/release calls are in fact in the wrong places because the only version that is actually tested is the ARC version.
GC tried the approach of ignoring retain/release calls in framework code that need to support both modes. It turned out that keeping a single codebase working both with and without GC was hard.
--
Greg Parker email@hidden Runtime Wrangler
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden