> On 10 Aug 2015, at 21:12, Dave <d...@looktowindward.com> wrote: > > >> On 10 Aug 2015, at 19:11, Uli Kusterer <witness.of.teacht...@gmx.net> wrote: >> >> On 10 Aug 2015, at 13:59, Dave <d...@looktowindward.com> 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 > >> 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). Cheers, -- Uli Kusterer "The Witnesses of TeachtText are everywhere..." _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
