Re: ARC and Manual Memory Management
Re: ARC and Manual Memory Management
- Subject: Re: ARC and Manual Memory Management
- From: SevenBits <email@hidden>
- Date: Mon, 10 Aug 2015 16:04:25 -0400
On Mon, Aug 10, 2015 at 3:51 PM, Uli Kusterer <email@hidden>
wrote:
>
> > On 10 Aug 2015, at 21:12, 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. But there is no point in worrying about it
> now since I can’t see them changing it!!! lol
>
That would be very confusing, however. Right now it's (relatively) easy to
tell whether a file has ARC enabled by looking for the presence of manual
retain and release calls. If the compiler simply ignored the statement, it
would not be very easy to tell (plus, having a program simply ignore a part
of its input for seemingly no reason is generally bad unless there's an
error).
> >
> >> Is there a reason why you can't add -fobjc-arc to the compiler flags
> for the files that use ARC in your non-ARC projects? That way, you can bit
> by bit move your project to ARC, yet don't have to manually manage the new
> code.
> >
> > That’s even more confusing then having them as no-ops, because it not
> obvious when you open a file whether it’s ARC or not and it’s quite hard to
> quickly find out.
> >
> >> The only reason I'm aware of is if you need to port to a platform that
> doesn't support libArclite (like really old Mac/iOS versions).
> >
> > Well, that wouldn’t work for categories on Cocoa objects, or would it?
>
> Why wouldn't it work for categories? The generated code contains
> retains/releases They're just implemented via objc_retain() instead of
> [retain]. Only the source is different.
>
> > I’m beginning to think that using the flag is the best option, or just
> forgetting about having a common source base and dupe them.
>
>
> You can use the flag others mentioned to turn off ARC, or (if you're not
> on old OSes where ARC is unavailable, but just running code that you
> haven't converted to ARC yet) the one I mentioned to turn it back on, IIRC.
> Also keep in mind that you can start your ARC-using files with
>
> #if __has_feature(objc_arc)
> #error This file needs ARC
> #endif
>
> to make it obvious they use ARC *and* to prevent yourself from shooting
> yourself in the foot in mixed code (I guess the errors you get from calling
> release should make it easy to detect non-ARC files under ARC).
>
For me, this mechanic is confusing, because at first glance it seems to
only specify whether the compiler supports ARC, and not whether it is
enabled on a given file. This has caused me confusion multiple times.
>
> Cheers,
> -- Uli Kusterer
> "The Witnesses of TeachtText are everywhere..."
>
>
>
>
> _______________________________________________
>
> 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
>
_______________________________________________
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