Literally all this does is enable ARC. Don't forget that Apple still allows
opt-out on a file by file basis for situations where ARC is not desired (such
as cases where the compiler isn't doing something that you want WRT retaining
objects outside of autorelease pools). This does not change the fact that the
viewer utilizes MRR and manual reference counting. NSAutoreleasePool is not
deprecated under this model, but it would largely need to be transitioned to
@autoreleasepool blocks instead which enables the compiler to decide how to
manage the pool, not the programmer when it comes to ARC or MRR. Additionally,
a couple of autoreleases would need to be removed, but that's only if you
intend to change from MRR+MRC to ARC.
It seems like you are complaining literally because "Apple made it the default
for new projects, so you should too!" Either way, MRR is here to stay. I
don't think anyone ever really disputed whether or not the viewer will or won't
compile with ARC enabled. Additionally, expanding upon your previous example,
the following function would not work in the garbage collector as it would
under MRR, nor would it function under ARC:
NSAutoreleasePool *pool = [[NSAutoreleasePool alloc]init]; // This is
unnecessary under GC, as the GC will collect objects automatically, whether
they're in a pool or not. It's not valid under ARC simply because the
compiler's job is to figure out how to manipulate a pool for you when it's
enabled.
// Any object allocated here under MRR that is not retained will be
released when the pool is either drained or released. See below for the
difference between the two.
[pool release]; // This is a no-op under GC, however 'drain' provides
a hint to the GC. Under MRR patterns, release will message any receiving
objects to dealloc "when their reference count reaches zero" - drain does the
same without the GC. ARC-enabled compilers like Clang will insert this for you
where necessary.
tl;dr, sure it'll fail to compile under ARC. It also won't really work with
the long deprecated GC either. But then, the code wasn't written with either
of these things in mind. Just the standard MRR and reference counting
environment of its time. I doubt anyone would complain if someone transitioned
from manual reference counting to automatic reference counting in the macOS
frontend, however - there shouldn't really be anything that would run afoul of
it that I'm aware of.
And before there's an argument over MRC vs. ARC - Obj-C's MRR with autorelease
pools still function on top of reference counting - just it's done manually by
the programmer (thus "Manual Retain-Release"), not automatically by the
compiler.
> On Jul 9, 2016, at 3:36 AM, Geir Nøklebye <geir.nokle...@dayturn.com> wrote:
>
> -fobjc-arcflag
_______________________________________________
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges
