Question

I’m looking over Apple’s sample application EditableDetailView, and noticed that in one of their controllers, they’re setting an instance of NSString property with (nonatomic, copy). When would one use copy instead of retain? Is this so they can make a unique copy without affecting the existing data?

Answer 1

Yes, it’s so that it can make a unique copy without affecting the existing data. The synthesized setters essentially look like this:

// For @synthesize(nonatomic, retain) foo: - (void) setFoo(NSFoo *theFoo) {     [theFoo retain];  // retain new value     [foo release];    // release old value, if any     foo = theFoo;     // assign new value }  // For @synthesize(nonatomic, copy) foo: - (void) setFoo(NSFoo *theFoo) {     NSFoo* newFoo = [theFoo copy];  // make copy     [foo release];  // release old value, if any     foo = newFoo;   // assign new value } 

Note the order of operations here is important – the new value must be retained/copied before the old value is released, in case of self-assignment. If you released first and then assigned the property to itself, you might deallocate the value by accident. Also note that if the old value is nil, sending it a release message is ok, since sending a message to a nil object is explicitly allowed and does nothing.

The choice of retaining versus copying just determines whether or not the object’s property shares the same value with what you’re setting it to. Consider the following code:

// suppose the 'foo' property is declared 'retain' and the 'bar' property is // declared 'copy' NSFoo *foo = ...; NSBar *bar = ...; someObject.foo = foo; someObject.bar = bar; [foo changeInternalState];  // someObject.foo also changes, since it's the same object [bar changeInternalState];  // someObject.bar does NOT change, since it's a copy