What is this new fangled ARC???

I've been working on my iOS programming since I am now out of school (well, I will be next week ) and I've noticed with XCode 4.2 it doesn't let me release objects in my programs anymore or create an autorelease pool and brings up a message about ARC (Automatic Reference Counting I'm guessing?)

Well, being a learner I don't want this feature since I want to manually manage my memory, but I am finding all kinds of crazy solutions on how to turn it off in XCode 4.2. Is there a simple way to do this that won't screw me up? I didn't see an option anywhere.

I've been working on my iOS programming since I am now out of school (well, I will be next week ) and I've noticed with XCode 4.2 it doesn't let me release objects in my programs anymore or create an autorelease pool and brings up a message about ARC (Automatic Reference Counting I'm guessing?)

Well, being a learner I don't want this feature since I want to manually manage my memory, but I am finding all kinds of crazy solutions on how to turn it off in XCode 4.2. Is there a simple way to do this that won't screw me up? I didn't see an option anywhere.

Click to expand...

ARC is an extension to Clang's static analysis, so in theory it is superior to standard Garbage Collection as there isn't or there isn't as much as a runtime hit.

ARC is part of LLVM and is enabled during compile time. To disable it you would need to change the compile command XCode uses when it compiles projects.

I've been working on my iOS programming since I am now out of school (well, I will be next week ) and I've noticed with XCode 4.2 it doesn't let me release objects in my programs anymore or create an autorelease pool and brings up a message about ARC (Automatic Reference Counting I'm guessing?)

Well, being a learner I don't want this feature since I want to manually manage my memory

Click to expand...

There is no advantage to not using ARC, especially because you're a beginner. The only time you wouldn't want to you ARC is if you want to support iOS 3 or you have weak references and want to support iOS 4.

I am finding all kinds of crazy solutions on how to turn it off in XCode 4.2. Is there a simple way to do this that won't screw me up? I didn't see an option anywhere.

Click to expand...

If you really want to do this, go in the Build Settings of your project. Under the Apple LLVM compiler 3.0 - Language group, you should find the Obejctive-C Automatic Reference Counting option which you can change to No.

The Automatice Reference Counting section of the Xcode New Features User Guide tell you about the new Xcode command for converting a project to ARC.

There is no advantage to not using ARC, especially because you're a beginner. The only time you wouldn't want to you ARC is if you want to support iOS 3 or you have weak references and want to support iOS 4.

If you really want to do this, go in the Build Settings of your project. Under the Apple LLVM compiler 3.0 - Language group, you should find the Obejctive-C Automatic Reference Counting option which you can change to No.

Click to expand...

Chrono1081 main area of specialization is games. In serious game programming, knowing when objects appear and disappear is a boone for optimizations.

Manual retaining/releasing your objects in WHATEVER project you are coding I still find it superior to anything that will autorelease it for me.
Why? because optimisations, Singletons, Improving your knowledge of MVC Patterns etc. Just so you perfectly know what you are coding, some will say, omg, ARC FOREVAR. But seriously, I know memory management sux, but I recommand it for every programmer since it will HELP you actually UNDERSTAND what you are doing.

Manual retaining/releasing your objects in WHATEVER project you are coding I still find it superior to anything that will autorelease it for me.
Why? because optimisations, Singletons, Improving your knowledge of MVC Patterns etc. Just so you perfectly know what you are coding, some will say, omg, ARC FOREVAR. But seriously, I know memory management sux, but I recommand it for every programmer since it will HELP you actually UNDERSTAND what you are doing.

Manual retaining/releasing your objects in WHATEVER project you are coding I still find it superior to anything that will autorelease it for me.
Why? because optimisations, Singletons, Improving your knowledge of MVC Patterns etc. Just so you perfectly know what you are coding, some will say, omg, ARC FOREVAR. But seriously, I know memory management sux, but I recommand it for every programmer since it will HELP you actually UNDERSTAND what you are doing.

Click to expand...

It doesn't hurt to understand manual memory management, but once you do there is no reason not to use ARC. The time savings in writing/maintaining/debugging your code will far outweigh whatever very meager (and probably nonexistent) performance gain you'll get by not doing it. In fact the @autoreleasepool directive in ARC is 6 times faster than using an NSAutoreleasePool, and all of the other memory management functions that ARC will use (retain/release/objc_msgSend) have been significantly optimized as well. I also don't know what it has to do with someone's ability to use MVC or any other pattern.

Garbage collection has never been available for iOS, for obvious reasons. The CPU time and memory cost of GC are simply too high for mobile devices. ARC bridges that gap nicely: takes the memory management out of the programmers' hands while not costing the system any extra loading (in fact, replacing -release messages with a shortcut that makes it even more efficient). This is the convergence of Mac OS and iOS.

I would not be surprised if GC were deprecated very soon, perhaps even causing applications that rely on it to become incompatible around the time of 10.8.x.

Manual retaining/releasing your objects in WHATEVER project you are coding I still find it superior to anything that will autorelease it for me.
Why? because optimisations, Singletons, Improving your knowledge of MVC Patterns etc. Just so you perfectly know what you are coding, some will say, omg, ARC FOREVAR. But seriously, I know memory management sux, but I recommand it for every programmer since it will HELP you actually UNDERSTAND what you are doing.

Click to expand...

ARC is entirely predictable about when things get deallocated. It's not like garbage collection, where things will get deallocated next time the collector runs — with ARC, as soon as there are no more strong references to an object, it's gone. There and then, immediately, as if you had written [object release] yourself on the next line.

(That's a simplification that doesn't mention autoreleasing and other such things, but it's all still predictable.)

Hence, there's no point doing manual memory management for the sake of optimisation. If you want to optimise, you can still do that with ARC (by checking where you assign nil to your strong references, for example). Also, with ARC, you get a whole bunch of speedup for free, because the release calls ARC makes behind the scenes are faster than an objective-C method call.

With old-fashioned garbage collection, I agree with you that often it's better to optimise things yourself. But given that ARC isn't non-deterministic in the same way, I reckon you'd have to be doing something crazy weird in order to benefit from manual memory management.

Are performance tools for checking for leaks and checking memory usage and such a thing of the past, then?

Click to expand...

No, because ARC doesn't prevent retain cycles from leaking. For example, if object A has a strong reference to object B, and object B has a strong reference to object A, but there are no other strong references to either object A or object B, those objects will never be dealloc'ed.

Yes if you only store object pointers in strong or week variables/properties.

But if you do something like store an object pointer in an __unsafe_unretained variable or property, or something like a void* variable using just a __bridge cast, then you still have the risk of zombies.

Note that under ARC, a property with the assign attribute is equivalent to __unsafe__unretained.

Just to clarify ARC is not Garbage Collection and ARC does not have an affect on runtime.

Click to expand...

From what I have been reading, the ARC mechanism does have an affect on runtime, and in some cases, it can be nontrivial. The hidden retains and releases short-circuit the message passing system, so the runtime effect would be a net positive (performance improvement). In heavy use code that is thick with retains and releases, this could theoretically provide observable speed gains. Or, in the case of a large object map thick with strong references, releasing a top end object could recurse through the implicit -deallocs more quickly.

ARC should be the opposite of a runtime hit.

Quote

You can turn ARC off per file or per project very easily by setting the following -fno-objc-arc.

Click to expand...

Would this mean that a project could mix ARC with manual reference counting? Would that work? Would it make sense?

Would this mean that a project could mix ARC with manual reference counting? Would that work? Would it make sense?

Click to expand...

Yes, just as it says, you can turn off ARC for individual files in a project. So some of your classes can use ARC, and others don't have to. There's not really any magic here; the compiler just won't insert any memory management functions in the non-ARC code like it would for the ARC-enabled code.

Think of ARC in this way; it's a fancy find and insert that follows the memory management rules. Considering memory management is a strict but simple rule set, its only a matter of adding release\autorelease\retain messages to code that requires it. This is done by the compiler so memory management messages are being inserted at compile time not runtime.

So yes, you may turn ARC on/off per file.

Quote

From what I have been reading, the ARC mechanism does have an affect on runtime, and in some cases, it can be nontrivial. The hidden retains and releases short-circuit the message passing system, so the runtime effect would be a net positive (performance improvement).

Click to expand...

Apple overhauled NSObject and optimized retain/release for performance. This is where and why you will see a performance increase with retain/release.

Quote

In heavy use code that is thick with retains and releases, this could theoretically provide observable speed gains. Or, in the case of a large object map thick with strong references, releasing a top end object could recurse through the implicit -deallocs more quickly.

Click to expand...

No, how do you figure that. ARC sends the same message of "release" as a developer would send. Remember you can still force destroy and setup autorelease pools, so how would you see a difference in performance. If you are handling memory poorly without ARC then yes you will see a performance increase.

There is no advantage to not using ARC, especially because you're a beginner.

Click to expand...

The major advantage of not using ARC is that only a microscopic fraction of the books, web tutorials, and even Apple's sample code shows how to use it.

Until the more popular iOS programming books are revised, I would leave ARC use to more expert programmers capable of figuring it out from Apple's terse documentation. This will have the major advantage that even if a new programmer eventually never uses manual memory management again after the major tutorials are revised, they will better understand what's going on the their app's memory footprint, and be in a far better position to debug things if they do accidentally code a retain loop or something.

@firewood, while I would tend to agree with you Apple doesn't. 4.2 has made changes that encourage you to use ARC. All the templates have no dealloc method. When you add outlets by dragging from a nib to a header file it doesn't add the release anymore to the code. I haven't taken the time yet to come up to speed on ARC but it seems clear that Apple wants developers to do it ASAP.

MacRumors attracts a broad audience
of both consumers and professionals interested in
the latest technologies and products. We also boast an active community focused on
purchasing decisions and technical aspects of the iPhone, iPod, iPad, and Mac platforms.