To use Automatic Reference Counting or not to use

Question

Im currently learning Objective C, and so far Ive been using Automatic Reference Counting with all my projects. However after speaking to some colleagues, and after looking at some forums online, Ive noticed a trend to turn off Automatic Reference Counting and manage memory manually.

Ive been wondering if ARC does a good enough job, or if it occasionally drops the ball. Is manually allocating/deallocating memory more efficient? Do some people turn ARC off because that is what they are used to?

Should I continue to use ARC? And if not, does anybody know of a point in the future where ARC will be good enough to use?

Answer 1

Your colleagues are wrong, or more likely, they don't want to convert to ARC for fear their expertise might be lost upon management when the next shuffle comes around.

Using ARC and the 64bit runtime will seriously clean up your code. I use ~30% fewer lines in ARC projects. In the long run you'll save days if not weeks on your projects. Personally I haven't needed to track down an autoreleased CALayer in any of my ARC projects.

Furthermore because the compiler uses lifetime qualifiers to annotate the life of your objects, it generally does a better job than you can. In heavily nested code, the last things you want to think about are release optimizations.

ARC will guide you to becoming a better programmer, but if it doesn't, you're on a better path than before. For instance, release/retain code has allowed people to get away with synthesized setter abuse for years (ie: creating a property just because self.property = property was nicer than [_property release], _property = [newProperty retain]). I'm fed up seeing explicit calls to setters via self.property. Because ARC takes retain and release away from you, there's no compelling reason to abuse property setters, your code starts to become more obvious and smell less.

Hope this helps!

Answer 2

Simple answer: Use ARC.

Long answer: Seriously, just use ARC.

I know of no compelling reason not to use ARC. It works. It's better than manual memory management. Use it. That said, you should still know what memory management is and how reference counting works. ARC does not change that behaviour at all, it simply adds in the required retain, release & autorelease calls to adhere to the conventions that have become standard when using Objective-C.

Answer 3

In most cases it should be more effective to use ARC than to handle your memorymanagement manually. If you do not need the compatibility for old iOS versions, do use ARC, it will do the job better than you. Even when there are some old frameworks who doesn't support ARC, you are able to deactivate it for only this files.

this blog is about a year old, but explains it in a good way: http://longweekendmobile.com/2011/09/07/objc-automatic-reference-counting-in-xcode-explained/

Answer 4

ARC does a far better job in memory handling then most humans will. Only in certain cases the use of ARC is better turned off, but I doubt many of us developers will ever need too.

Also see : To ARC or not to ARC? What are the pros and cons?

Answer 5

When ARC was announced, I was tempted to avoid it. The reason is, I've spent a lot of time working with Java and have seen that automatic memory management is capable of making programmers forget about logical structure for object relationships and induces them to create the OOP equivalent of "spaghetti code".

So far, what I've seen with ARC doesn't support that fear. Because of weak and strong designations, people still have to consider object lifecycles but with less typing. When I answer questions here from people who have memory management problems in an ARC environment, it's because of code that would also have been a problem with non-ARC.

I now don't see a downside.