Understanding reference counting with Cocoa and Ob

Question

I'm just beginning to have a look at Objective-C and Cocoa with a view to playing with the iPhone SDK. I'm reasonably comfortable with C's malloc and free concept, but Cocoa's references counting scheme has me rather confused. I'm told it's very elegant once you understand it, but I'm just not over the hump yet.

How do release, retain and autorelease work and what are the conventions about their use?

(Or failing that, what did you read which helped you get it?)

Answer 1

The answers above give clear restatements of what the documentation says; the problem most new people run into is the undocumented cases. For example:

• Autorelease: docs say it will trigger a release "at some point in the future." WHEN?! Basically, you can count on the object being around until you exit your code back into the system event loop. The system MAY release the object any time after the current event cycle. (I think Matt said that, earlier.)

• Static strings: NSString *foo = @"bar"; -- do you have to retain or release that? No. How about

  -(void)getBar {
      return @"bar";
  }
  

  ...

  NSString *foo = [self getBar]; // still no need to retain or release
  

• The Creation Rule: If you created it, you own it, and are expected to release it.

In general, the way new Cocoa programmers get messed up is by not understanding which routines return an object with a retainCount > 0.

Here is a snippet from Very Simple Rules For Memory Management In Cocoa:

Retention Count rules

• Within a given block, the use of -copy, -alloc and -retain should equal the use of -release and -autorelease.
• Objects created using convenience constructors (e.g. NSString's stringWithString) are considered autoreleased.
• Implement a -dealloc method to release the instancevariables you own

The 1st bullet says: if you called alloc (or new fooCopy), you need to call release on that object.

The 2nd bullet says: if you use a convenience constructor and you need the object to hang around (as with an image to be drawn later), you need to retain (and then later release) it.

The 3rd should be self-explanatory.

Answer 2

Matt Dillard wrote:

return [[s autorelease] release];

Autorelease does not retain the object. Autorelease simply puts it in queue to be released later. You do not want to have a release statement there.

Answer 3

Joshua (#6591) - The Garbage collection stuff in Mac OS X 10.5 seems pretty cool, but isn't available for the iPhone (or if you want your app to run on pre-10.5 versions of Mac OS X).

Also, if you're writing a library or something that might be reused, using the GC mode locks anyone using the code into also using the GC mode, so as I understand it, anyone trying to write widely reusable code tends to go for managing memory manually.

Answer 4

There's a free screencast available from the iDeveloperTV Network

Memory Management in Objective-C

Answer 5

If you understand the process of retain/release then there are two golden rules that are "duh" obvious to established Cocoa programmers, but unfortunately are rarely spelled out this clearly for newcomers.

1. If a function which returns an object has alloc, create or copy in its name then the object is yours. You must call [object release] when you are finished with it. Or CFRelease(object), if it's a Core-Foundation object.

2. If it does NOT have one of these words in its name then the object belongs to someone else. You must call [object retain] if you wish to keep the object after the end of your function.

You would be well served to also follow this convention in functions you create yourself.

(Nitpickers: Yes, there are unfortunately a few API calls that are exceptions to these rules but they are rare).

Answer 6

As ever, when people start trying to re-word the reference material they almost invariably get something wrong or provide an incomplete description.

Apple provides a complete description of Cocoa's memory management system in Memory Management Programming Guide for Cocoa, at the end of which there is a brief but accurate summary of the Memory Management Rules.