Objective-C Fundamentals

184 CHAPTER 9 Memory management
Now that you have a solid understanding of the retain and release messages, you
can apply that knowledge to virtually any Objective-C or Cocoa Touch memory management
technique. These two messages are the fundamental building blocks upon
which all other techniques are ultimately placed.
This isn’t to say that retain and release are the perfect memory management
tools. Both messages have deficiencies or scenarios under which their usage can be
painful. As an example, manual management of an object’s retain count can get laborious
if an object is constantly passed among numerous owners. The next memory
management technique we investigate builds on top of the retain and release foundations
and is designed to ease such burdens.
9.3 Autorelease pools
The retain/release model has difficulties when ownership of an object needs to be
transferred or handed off to something else. The code performing the transfer
doesn’t want to continue retaining the object, but neither do you want the object to
be destroyed before the handoff can take place.
Consider the following method, which attempts to create a new NSString object
and return it to the caller:
- (NSString *)CreateMessageForPerson:(NSString *)name {
NSString *msg = [[NSString alloc] initWithFormat:@"Hello, %@", name);
return msg;
}
The first line of the CreateMessageForPerson: method allocates a new string object.
Since the string is created via the alloc message, the method currently owns the created
string. Once the method returns, however, it’ll never need to refer to the string
again, so before returning, it should release its ownership.
A temping solution may be to rework the CreateMessageForPerson method
as follows:
- (NSString *)CreateMessageForPerson:(NSString *)name {
NSString *msg = [[NSString alloc] initWithFormat:@"Hello, %@", name];
[msg release];
return msg;
}
This solution, however, has the same bug as previously discussed. The first line creates
a new string object with a retain count of 1, and the next decrements the retain count
back to zero, causing the string to be deallocated. The pointer to the deallocated
object is then returned.
The problem with the retain/release model in this solution is that there’s no suitable
location to place the call to release.
If the call to release occurs in the CreateMessageForPerson method, you can’t pass
the string back to the caller. On the other hand, if you don’t release the object in the
method, you push the responsibility of freeing the string object onto every caller. This
not only is error prone but breaks the principle of “match every retain with a release.”