> On Aug 10, 2015, at 12:12 PM, 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.
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 gpar...@apple.com Runtime Wrangler _______________________________________________ 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
