2

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?

Jimmery
  • 9,783
  • 25
  • 83
  • 157
  • possible duplicate of [To ARC or not to ARC? What are the pros and cons?](http://stackoverflow.com/questions/8760431/to-arc-or-not-to-arc-what-are-the-pros-and-cons) – ughoavgfhw Oct 25 '12 at 01:32

5 Answers5

5

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.

mattjgalloway
  • 34,792
  • 12
  • 100
  • 110
3

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?

Community
  • 1
  • 1
ekinsol
  • 501
  • 1
  • 3
  • 9
  • Cheers for the link to that discussion. I searched SO for any debate on automatic reference counting, but couldnt find anything. I was obviously typing in the wrong things, because this is exactly what I was looking for. – Jimmery Oct 24 '12 at 11:46
2

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.

Phillip Mills
  • 30,888
  • 4
  • 42
  • 57
  • ARC is not garbage collection. So it's vastly different to the automatic memory management of something like Java. – mattjgalloway Oct 24 '12 at 12:08
  • Understood. Before actually using it, I didn't realize the implications of that as they applied to object organization and design. – Phillip Mills Oct 24 '12 at 12:28
1

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/

Herm
  • 2,956
  • 19
  • 32
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!

Matt Melton
  • 2,493
  • 19
  • 25