Object Reference and Object Ownership

An Objective-C object is accessed by indirection through a variable that points to the memory address of the Objective-C object. This variable, also called a pointer, is declared by prefixing its name with an asterisk. The following statement

Hydrogen *atom;

declares a pointer variable named atom that points to an object of type Hydrogen. Note that pointers and indirection can be used for any Objective-C data type, including primitives and C data types; however, object pointers are used specifically for interacting with Objective-C objects.

An object pointer enables access to an Objective-C object, but does not by itself manage ownership. Look at the following code:

Hydrogen *atom = [Hydrogen init];
...
Hydrogen *href = atom;

The pointer href is declared and assigned to a Hydrogen object named atom, but href does not (by assignment) claim an ownership interest in this object. Hence, if atom is deallocated, href will no longer point to a valid object. Thus, to manage the life cycle (i.e., the existence) of an object using MRR, your code must observe a set of memory management rules. You’ll look at these next.

Basic Memory Management Rules

To use MRR correctly, your code needs to balance ownership claims on an object with those releasing ownership claims on the object. In order to support this requirement, you should write your code observing the MRR basic memory-management rules, as follows:

• Claim ownership interest in any object that you create. You create an Objective-C object with a method whose name begins with alloc, new, copy, or mutableCopy. You also dynamically create an Objective-C block object by sending the copy message to the block.
• Take ownership interest in an object (that you don’t already own) using the retain method. NSObject implements a retain method that is used to take ownership interest in an object. Under normal circumstances, an object is guaranteed to remain valid both within the method it is received (as a parameter), and as a return value. The retain method is used to take ownership of an object that you want to use over a long period of time, typically to store it as a property value, or to prevent it from being deallocated as a side effect of some other operation.
• You must relinquish ownership of objects you own when no longer needed. NSObject implements the release and autorelease methods that are used to relinquish ownership interest in an object. The autorelease method relinquishes ownership interest of an object at the end of the current autorelease block. The release method immediately relinquishes ownership interest in an object. Both methods send the dealloc method on an object if its retain count equals zero.
• You must not relinquish ownership of objects you do not own. This could cause such objects to be released prematurely. If a program attempts to access an object that has already been deallocated, it will cause an error.

Listing 4-2 shows an example that illustrates application of the MRR basic memory-management rules.

Listing 4-2.  MRR Example Usage

Hydrogen *atom = [Hydrogen init];
...
Hydrogen *href = [atom retain];
...
[atom release];
...
[href release];

A Hydrogen object is created and assigned to a variable named atom. Since the object is created with an alloc message, atom has an ownership interest in this object. Later in the code, a variable named href takes an ownership interest in this object, thereby increasing the retain count (i.e., the number of ownership interests) in the object. Later, a release message is sent to the atom variable. As href still has an ownership interest in the object, it is not deallocated. Once href sends a release message to the object, its retain count drops to zero and it can be deallocated by the runtime.

@autorelease
{
  // Code that creates autoreleased objects
  ...
}

int main(int argc, const char * argv[])
{
  @autorelease
  {
    Hydrogen *atom = [[[Hydrogen alloc] init] autorelease];
    ...
  }
  return 0;
}

Using MRR

Now that you’ve gone over Objective-C memory management and MRR, it’s time to apply what you’ve learned by developing an example program! This example will demonstrate the application of the MRR basic memory-management rules, along with usage of the corresponding APIs. Briefly, the program consists of three classes: an OrderEntry class used to record product orders, and the dependent classes OrderItem and Address. The OrderItem class encapsulates the state and behaviors specific to an order entry item, and the Address class consists of the state and behavior associated with an order entry shipping address. Each OrderEntry object has a corresponding OrderItem object and Address object (as shown in Figure 4-3).

You will develop these classes using MRR memory management, and then test them to demonstrate proper use of this memory-management technique. In Xcode, create a new project by selecting New Project ... from the Xcode File menu. In the New Project Assistant pane, create a command-line application (choose Command Line Tool from the Mac OS X Application selection) and click Next. In the Project Options window, specify MRR Orders for the Product Name, set the Type to Foundation, select MRR memory management by unchecking the Use Automatic Reference Counting check box (as shown in Figure 4-4), and then click Next.

Specify the location in your file system where you want the project to be created (if necessary, select New Folder and enter the name and location for the folder), uncheck the Source Control check box, and then click the Create button.

Now let’s add the OrderEntry, OrderItem, and Address classes. As you’ve done in previous chapters, add each class to the project by selecting New File ... from the Xcode File menu, selecting the Objective-C class template, naming the class appropriately (each is a subclass of NSObject), then selecting the MRR Orders folder for the files location and the MRR Orders project as the target.

Your project now has files for three classes along with the main.m file. Next, let’s implement the Address class. You are not going to add any instance variables, properties, or methods to the class, so you won’t be editing the Address interface. However, you will edit the Address implementation by overriding the default init and dealloc methods provided by its superclass (NSObject). Select the Address.m file in the navigator pane, and then add the code shown in Listing 4-5.

Listing 4-5.   MRR Address Class Implementation

#import "Address.h"

@implementation Address
- (id) init
{
  if ((self = [super init]))
  {
    NSLog(@"Initializing Address object");
  }
  return self;
}

- (void)dealloc
{
  NSLog(@"Deallocating Address object");
  [super dealloc];
}
@end

As you can see in Listing 4-5, the init and dealloc methods each log a message to the console to show method entry. When you test the program, this enables you to see when the runtime invokes each of these methods. In addition, the dealloc method invokes dealloc on its superclass, thereby ensuring the object’s memory is reclaimed. OK, you’re done with the Address class; now let’s implement the OrderItem class.

Select the OrderItem.h file in the navigator pane, and then add the code shown in Listing 4-6.

Listing 4-6.  MRR OrderItem Class Interface

#import <Foundation/Foundation.h>

@interface OrderItem : NSObject
{
@public NSString *name;
}

- (id) initWithName:(NSString *)itemName;
@end

The OrderItem class adds a public instance variable named name of type (NSString *), and a custom initializer (initWithName:) that takes an input parameter also of type (NSString *). Next, select the OrderItem.m file and implement the OrderItem class, as shown in Listing 4-7.

Listing 4-7.  MRR OrderItem Class Implementation

#import "OrderItem.h"

@implementation OrderItem
- (id) initWithName:(NSString *)itemName
{
  if ((self = [super init]))
  {
    NSLog(@"Initializing OrderItem object");
    name = itemName;
    [name retain];
  }
  return self;
}

- (void)dealloc
{
  NSLog(@"Deallocating OrderItem object");
  [name release];
  [super dealloc];
}
@end

The custom initializer assigns the instance variable to the input parameter. Since the OrderItem object did not create the input parameter, it doesn’t have an ownership interest in it. However, as you don’t want this object to be deallocated as a side effect of some other operation (and also require it to be valid throughout the object’s lifetime), you send a retain message to the name variable, thereby taking an ownership interest in the object. In the dealloc method, you send a release message to the name object, then invoke dealloc on its superclass to relinquish the OrderItem object’s memory.

Now let’s implement the OrderEntry class. Select the OrderEntry.h file and code the interface (as shown in Listing 4-8).

Listing 4-8.  MRR OrderEntry Class Interface

#import <Foundation/Foundation.h>
#import "OrderItem.h"
#import "Address.h"

@interface OrderEntry : NSObject
{
@public OrderItem *item;
NSString *orderId;
Address *shippingAddress;
}

- (id) initWithId:(NSString *)oid;
@end

Listing 4-8 shows that an OrderEntry object has three instance variables and a custom initializer (initWithId:). Next, select the OrderEntry.m file and implement the OrderEntry class, as shown in Listing 4-9.

Listing 4-9.  MRR OrderEntry Class Implementation

#import "OrderEntry.h"

@implementation OrderEntry
- (id) initWithId:(NSString *)oid
{
  if ((self = [super init]))
  {
    NSLog(@"Initializing OrderEntry object");
    orderId = oid;
    [orderId retain];
    item = [[OrderItem alloc] initWithName:@"Doodle"];
    shippingAddress = [[Address alloc] init];
  }
   
  return self;
}

- (void)dealloc
{
  NSLog(@"Deallocating OrderEntry object");
  [item release];
  [orderId release];
  [shippingAddress release];
  [super dealloc];
}
@end

The custom initializer assigns the input parameter to the orderId instance variable, and then creates and initializes OrderItem and Address objects. As the OrderEntry object has an ownership interest in the OrderItem and Address objects, and also the orderId instance, it is responsible for releasing them prior to it being deallocated. This is accomplished in the dealloc method, which then invokes dealloc on its superclass to relinquish the OrderEntry object’s memory.

So you’ve implemented the order entry classes, now test the classes to validate the implementation and also verify that you used MRR correctly. Select the main.m file in the navigator pane, and then update the main() function as shown in Listing 4-10.

Listing 4-10.  MRR main() Function Implementation

#import <Foundation/Foundation.h>
#import "OrderEntry.h"

int main(int argc, const char * argv[])
{
  @autoreleasepool
  {
    // Create an OrderEntry object for manual release
    NSString *orderId = [[NSString alloc] initWithString:@"A1"];
    OrderEntry *entry = [[OrderEntry alloc] initWithId:orderId];

    // Release orderId (retained by OrderEntry, so object not deallocated!)
    [orderId release];
    NSLog(@"New order, ID = %@, item: %@", entry->orderId, entry->item->name);
     
    // Must manually release OrderEntry!
    [entry release];
     
    // Create an autorelease OrderEntry object, released at the end of
    // the autorelease pool block
    OrderEntry *autoEntry = [[[OrderEntry alloc] initWithId:@"A2"] autorelease];
    NSLog(@"New order, ID = %@, item: %@", autoEntry->orderId, autoEntry->item->name);
  }
  return 0;
}

The main() function demonstrates MRR memory management by creating OrderEntry objects and releasing them, along with the objects it has an ownership interest in, according to the memory-management rules. The first OrderEntry object is manually released, while the second is created with autorelease, and thus is released at the end of its surrounding autorelease pool block.

Now save, compile, and run the MRR Orders program and observe the messages in the output pane (as shown in Figure 4-5).

The messages show the sequence of calls to initialize and deallocate the dynamically created objects. It looks like all the object create/retain and release messages are correctly balanced, and the tests you ran displayed the appropriate output, so you’re all done, right? Well, not quite. After all, how do you know for sure that the program doesn’t have a memory leak—it could display the correct output but still have an undetected problem. So, how do you verify that the program isn’t leaking memory or has some other undetected problem? Xcode has a suite of tools that can be used to analyze your program and detect potential problems. In Appendix B, you’ll learn how to use the Xcode Instruments tool to do just that, but here you’ll use Xcode’s Build and Analyze tool to perform an initial check of the application.

Select Analyze from the Xcode Product menu. The tool performs an analysis of the program, detecting, among other things, any potential memory leaks or dangling pointers. If an error(s) is detected, it identifies the error. Now observe the Activity View in the middle of the toolbar; it should display “Analyze Succeeded,” meaning that no memory-management errors were detected. In the main() function, comment-out the [orderId release] statement, and then run the Build and Analyze tool again. It should display the message shown in Figure 4-6.

As shown in Figure 4-6, when a dynamically allocated object (orderId in this case) does not have a balanced set of retain/release messages, a potential memory leak is detected. This demonstrates that the Build and Analyze tool is great for performing an initial first-check on program memory management. Now, go ahead and remove the comment markers from your program—you’ve proven that it manages memory correctly using MRR. Great job!

Rules and Conventions for Using ARC

As mentioned, ARC greatly simplifies memory management with respect to the MRR method. As a result, there are different sets of rules for object memory management under ARC. These rules are as follows:

• You cannot send retain, retainCount, release, autorelease, or dealloc messages. ARC forbids programmatic control of an object life cycle and automatically inserts these messages where required during compilation. This includes @selector(retain), @selector(release), and related methods. You may implement a dealloc method if you need to manage resources other than instance variables. ARC automatically creates a dealloc method in your classes (if not provided) to release the objects it owns, and invokes [super dealloc] in your implementation(s) of the dealloc method.
• You can’t cast directly between id and (void *) types. ARC only manages Objective-C objects and blocks, thus the compiler needs to know the types of the objects it is processing. Because a pointer to void (void *) is a generic pointer type that can be converted to any other pointer type (even those that are not Objective-C pointer types), this restriction is necessary. This scenario is common when casting between Foundation Framework objects and Core Foundation types (Core Foundation is an Apple software library that provides C-language APIs). A set of APIs is provided for ownership transfer of variables between ARC and non-ARC environments.
• Autorelease pool blocks should be used to perform ARC-managed autorelease of objects.
• You cannot call the Foundation Framework functions NSAllocateObject and NSDeallocateObject. These functions provide the capability to allocate and deallocate memory for an object in a specific memory zone. Because zone-based memory is no longer supported, these functions cannot be used.
• You cannot use object pointers in C structures (structs). ARC does not perform memory management for dynamically allocated C structures, thus the compiler cannot determine where to insert the necessary retain and release messages.
• You cannot use memory zones (NSZone). As mentioned, zone-based memory is no longer supported.
• To properly cooperate with non-ARC code, you cannot create a method or a declared property (unless you explicitly choose a different getter) that begins with “copy”.
• By default, ARC is not exception-safe: it does not end the lifetime of __strong variables whose scope is abnormally terminated by an exception, and it does not perform releases of objects that would occur at the end of a full-expression if that full-expression throws an exception. The compiler option -fobjc-arc-exceptions can be used to enable exception handling for ARC code. ARC does end the lifetimes of weak references when an exception terminates their scope, unless exceptions are disabled in the compiler.

ARC Lifetime Qualifiers

There are a set of ARC-specific qualifiers that declare the object lifetime for both regular variables and properties. The following are those for regular variables:

• __strong: Any object created using alloc / init is retained for the lifetime of its current scope. This is the default setting for regular variables. The “current scope” usually means the braces in which the variable is declared (a method, for loop, if block, etc.)
• __weak: The object can be destroyed at anytime. This is only useful if the object is somehow strongly referenced somewhere else. When destroyed, a variable with __weak is set to nil.
• __unsafe_unretained: This is just like __weak but the pointer is not set to nil when the object is deallocated. Instead, the pointer is left dangling (i.e., it no longer points to anything useful).
• __autoreleasing: Not to be confused with calling autorelease on an object before returning it from a method, this is used for passing objects by reference.

When using ARC lifetime qualifiers to declare variables for Objective-C objects, the correct syntax is

ClassName *qualifier varName;

ClassName is name/type of the class (OrderEntry, etc.), qualifier is the ARC lifetime qualifier (as previously listed), and varName is the name of the variable. If no qualifier is specified, the default is __strong. The ARC-specific lifetime qualifiers for properties are as follows:

• strong: The strong attribute is equivalent to the retain attribute (the complete list of property attributes is provided in Appendix A).
• weak: The weak attribute is similar to the assign attribute, except that if the affected property instance is deallocated, its instance variable is set to nil.

Under ARC, strong is the default ownership attribute for object-type properties.

Using ARC

Now you are going to develop an example program that uses ARC. You’ll take the program you built earlier that uses MRR memory management (OrderEntry) and create a new version that uses ARC memory management. This will enable you to get some hands-on experience programming with ARC and also see how it simplifies application memory management. As you may recall, the OrderEntry program you developed earlier consists of three classes: an OrderEntry class used to record product orders, and the dependent classes OrderItem and Address.

In Xcode, create a new project by selecting New Project ... from the Xcode File menu. In the New Project Assistant pane, create a command-line application (choose Command Line Tool from the Mac OS X Application selection) and click Next. In the Project Options window, specify ARC Orders for the Product Name and select ARC memory management by checking the Use Automatic Reference Counting check box, and then click Next.

Specify the location in your file system where you want the project to be created (if necessary, select New Folder and enter the name and location for the folder), uncheck the Source Control check box, and then click the Create button.

Now let’s add the OrderEntry, OrderItem, and Address classes. As you’ve done before, add each class to the project by selecting New File ... from the Xcode File menu, selecting the Objective-C class template, naming the class appropriately (each is a subclass of NSObject), and then selecting the ARC Orders folder for the files location and the ARC Orders project as the target.

Your project now has files for three classes along with the main.m file. Next, implement the Address class. Proceeding as you did with the MRR Orders project, you’ll edit the Address class implementation by overriding the default init and dealloc methods provided by its superclass (NSObject). Select the Address.m file in the navigator pane, and then add the code, as shown in Listing 4-11.

Listing 4-11.  ARC Address Class Implementation

#import "Address.h"

@implementation Address
- (id) init
{
  if ((self = [super init]))
  {
    NSLog(@"Initializing Address object");
  }
  return self;
}

- (void)dealloc
{
  NSLog(@"Deallocating Address object");
}
@end

Listing 4-11 shows the init method is the same as that provided for MRR Address class. The dealloc method is different; it does not invoke dealloc on its superclass because this is automatically performed by ARC. Now let’s implement the ARC OrderItem class.

The ARC OrderItem interface is the same as that provided for the MRR OrderItem class. Select the OrderItem.h file and copy the interface shown in Listing 4-6. Next, select the ARC OrderItem.m file and implement the OrderItem class, as shown in Listing 4-12.

Listing 4-12.  ARC OrderItem Class Implementation

#import "OrderItem.h"

@implementation OrderItem
- (id) initWithName:(NSString *)itemName
{
  if ((self = [super init]))
  {
    NSLog(@"Initializing OrderItem object");
    name = itemName;
}
  return self;
}

- (void)dealloc
{
  NSLog(@"Deallocating OrderItem object);
}
@end

The custom initializer is very similar to that provided for the MRR OrderItem class. It differs in that it doesn’t invoke the retain method on the name instance variable, as you cannot send retain, release, or autorelease messages with ARC. The dealloc method is also different from that provided for the MRR OrderItem class; it merely logs a message to the output console. ARC automatically sends a release message to all the objects that the OrderItem class has an ownership interest in, and also invokes dealloc on its superclass.

Now you’ll implement the ARC OrderEntry class. The interface is identical to that of the MRR OrderEntry class. Select the ARC OrderEntry interface (OrderEntry.h) and copy the interface shown in Listing 4-8.

Next, select the OrderEntry.m file and implement the OrderEntry class, as shown in Listing 4-13.

Listing 4-13.  ARC OrderEntry Class Implementation

#import "OrderEntry.h"

@implementation OrderEntry
- (id) initWithId:(NSString *)oid
{
  if ((self = [super init]))
  {
    NSLog(@"Initializing OrderEntry object");
    orderId = oid;
    item = [[OrderItem alloc] initWithName:@"Doodle"];
    shippingAddress = [[Address alloc] init];
  }
   
  return self;
}

- (void)dealloc
{
  NSLog(@"Deallocating OrderEntry object with ID %@", orderId);
}
@end

The custom initializer is very similar to that provided for the MRR OrderEntry class. It differs in that it doesn’t invoke the retain method on the orderId instance variable; as noted previously, you cannot send retain/release/autorelease messages with ARC. The dealloc method is also different from that provided for the MRR OrderEntry class; it merely logs a message to the output console. ARC automatically sends a release message to all the objects that the OrderItem class has an ownership interest in, and also invokes dealloc on its superclass.

Now let’s implement the ARC Orders main() function. Select the main.m file in the navigator pane, and then update the main() function, as shown in Listing 4-14.

Listing 4-14.  ARC main() Function Implementation

#import <Foundation/Foundation.h>
#import "OrderEntry.h"

int main(int argc, const char * argv[])
{

  @autoreleasepool
  {
    // Create an OrderEntry object for manual release
    NSString *a1 = @"A1";
    NSString *orderId = [[NSString alloc] initWithString:a1];
    OrderEntry *entry = [[OrderEntry alloc] initWithId:orderId];
     
    // Set ID to nil to verify that value was retained by ARC!
    a1 = nil;
     
    // View results for new order entry, should display valid ID!
    NSLog(@"New order, ID = %@, item: %@", entry->orderId, entry->item->name);
     
    // Now set OrderEntry object to nil, it can now be deallocated by ARC!
    entry = nil;
     
    // Create another OrderEntry object
    OrderEntry *autoEntry = [[OrderEntry alloc] initWithId:@"A2"];
    NSLog(@"New order, ID = %@, item: %@", autoEntry->orderId,          autoEntry->item->name);
  }
  return 0;
}

The main() function demonstrates ARC memory management by creating OrderEntry objects. They are automatically released by ARC when the objects are no longer in use. The function also demonstrates that classes developed with ARC acquire ownership interest in dependent objects as necessary, thereby preventing objects from being changed or deallocated while they are still in use.

Now save, compile, and run the ARC Orders program, and observe the messages in the output pane (as shown in Figure 4-7).

The messages show the sequence of calls to initialize and deallocate the dynamically created objects. You can see that ARC memory management performed correctly, releasing all dynamically created objects when they were no longer in use. You can also perform an initial first-check of program memory management by selecting Analyze from the Xcode Product menu. Comparing the MRR Orders project and the ARC Orders project, notice how it significantly reduced the amount of code you had to write. As your projects grow in size and complexity, the advantages of ARC become even more pronounced. Because ARC can be selected on a file-by-file basis and ARC-compiled code can be used alongside existing code built using MRR, there’s no reason not to use it on your projects. In fact, ARC is the Apple-recommended mechanism for memory management on new Objective-C projects.

Avoiding Circular References

The Objective-C reference counting model is implemented by taking ownership interest in an object (via a retain message), and then releasing ownership interest (via a release message) when that object is no longer needed. This process is automated with ARC, which automatically inserts retain/release/autorelease messages in the code where needed. However, in an object graph, a problem of circular references can arise if two objects in the graph have circular references. For example, in the preceding ARC Orders project, an OrderEntry object has an OrderItem instance variable, which is by default a strong reference. Now if an OrderItem object also had an OrderItem instance variable, this could create a circular reference between the two objects. If this were to occur, neither object could ever be deallocated, therefore causing a memory leak. In effect, the OrderEntry object could not be released until the OrderItem object is released, and the OrderItem object couldn’t be released until the OrderEntry object is released. The solution to this problem is to use weak references. A weak reference is a non-owning relationship; that is, the object declared as a weak reference is not owned by the declaring object, hence eliminating the circular reference. The Apple Objective-C convention for object graphs is for the parent object to maintain a strong reference to each of its child objects, while the child objects maintain a weak reference (if necessary) to the parent object. Thus, in this example, the OrderEntry object would have a strong reference to its OrderItem object, while the OrderItem object would have a weak reference to its parent, OrderEntry object. A weak reference would be declared in the OrderItem class (as shown in Listing 4-15).

Listing 4-15.  Declaring a Weak Reference

#import <Foundation/Foundation.h>

@interface OrderItem : NSObject

{
@public NSString *name;
OrderEntry *__weak entry;
}

- (id) initWithName:(NSString *)itemName;

@end

When destroyed, the entry variable is set to nil, thereby avoiding a circular reference.