Need for release with assign attribute p56


P56 at the bottom explains the second retain count rule about becoming the owner of an object and needing to release copied objects unless it is defined with an assign attribute because this is a simple pointer assignment. This has confused me a little.

Do you mean that whenever a pointer is assigned by a setter, we can trust by convention that it will be to an autoreleased object? Can you give me an example of this scenario where you mean that the setter is a simple pointer assignment.

Thanks in advance.



Typically, you have an assign-only setter in situations that may create retain cycles.

Let’s look ahead a couple of chapters at the Core Location stuff. The controller (WhereamiAppDelegate) creates and takes ownership of a CLLocationManager (locationManager). The locationManager is then given a delegate, the instance of WhereamiAppDelegate that owns it. If (for sake of discussion) the locationManager retained its delegate, the locationManager would own the WhereamiAppDelegate and the WhereamiAppDelegate would own the locationManager. These objects could never be deallocated.

Why? An application is essentially a graph of objects with relationships to each other; the application’s behavior is defined by the messaging that goes on between these objects. When an object is no longer needed, it is unlinked from this graph and its memory returned to the heap.

Let’s say the WhereamiAppDelegate is unlinked from the object graph that makes up your application. You would think, then, that this WhereamiAppDelegate would be deallocated because no other objects can access it anymore. And by deallocating the WhereamiAppDelegate, it would release its locationManager causing the locationManager to be deallocated as well. This makes sense, because we’re unlinking these objects from the rest of the application because we don’t want to use them anymore.

However, the locationManager took ownership of the WhereamiAppDelegate. The WhereamiAppDelegate still exists because the locationManager told it to stick around. The locationManager can send messages to the WhereamiAppDelegate and the WhereamiAppDelegate can send messages to the locationManager. However, these objects are completely unlinked from the rest of the application’s objects and can’t have an effect on the application anymore because they can only talk to each other. They’re the nerdy kids at the far end of the cafeteria - they’re keeping each other entertained, but no one else cares.

If the WhereamiAppDelegate was not retained by the locationManager, when the WhereamiAppDelegate was unlinked from the object graph, it would be deallocated (it was only owned by the object that was unlinking it). In turn, it would cause the locationManager to be deallocated. And that’s good; these objects weren’t going to be used by the application anymore.

So, assign-only is used in situations where you are giving an object a pointer to the object that owns it. While there are other situations where using assign may be useful, this is the big one. Drawing an object graph of your application is helpful in this situation. Run through that object graph and figure out what would happen, giving the relationships between the objects, if one of these objects were to be unlinked.


Excellent explanation. I really appreciate the trouble you have taken to clarify this and at the weekend too. The more you get to understand memory management I can see how you can create well behaved apps that perform smoothly too.