{"id":167,"date":"2008-11-14T20:11:17","date_gmt":"2008-11-15T01:11:17","guid":{"rendered":"http:\/\/vgable.com\/blog\/2008\/11\/14\/prefer-copy-over-retain\/"},"modified":"2009-11-10T19:30:00","modified_gmt":"2009-11-11T00:30:00","slug":"prefer-copy-over-retain","status":"publish","type":"post","link":"https:\/\/vgable.com\/blog\/2008\/11\/14\/prefer-copy-over-retain\/","title":{"rendered":"Prefer copy Over retain"},"content":{"rendered":"

(Almost) every time you use retain<\/code> in Objective-C\/Cocoa, you really should be using copy<\/code>. Using retain<\/code> can introduce some subtle bugs, and copy<\/code> is faster then you think…<\/p>\n

A Bug Waiting To Bite<\/h3>\n

The problem with using retain<\/code> to “take ownership<\/a>” of an object is that someone else has a pointer to the same object, and if they change it, you will be affected.<\/strong><\/p>\n

For example, let’s say you have a Person<\/code> class with a straightforward setter method:
\n- (void) setThingsToCallTheBossToHisFace:(NSArray*)newNames {
\n   [thingsToCallTheBossToHisFace autorelease];
\n   thingsToCallTheBossToHisFace = [newNames retain];
\n}
<\/code><\/p>\n

And you use it to initialize a few Person<\/code> objects:<\/p>\n

NSMutableArray *appropriateNames = [NSMutableArray arrayWithObject:@\"Mr. Smith\"];
\n[anIntern setThingsToCallTheBossToHisFace:appropriateNames];<\/p>\n

\/\/Salaried Employees can also be a bit more informal
\n[appropriateNames addObject:@\"Joe\"];
\n[aSalariedEmployee setThingsToCallTheBossToHisFace:appropriateNames];<\/p>\n

\/\/the wife can also use terms of endearment
\n[appropriateNames addObject:@\"Honey\"];
\n[appropriateNames addObject:@\"Darling\"];
\n[theBossesWife setThingsToCallTheBossToHisFace:appropriateNames];
<\/code>
\n
\nThe code looks good, it compiles without error, and it has a bug in it. Because setThingsToCallTheBossToHisFace:<\/code> uses retain<\/code>, each Person<\/code> object’s thingsToCallTheBossToHisFace<\/code> field is actually pointing to the exact same NSMutableArray<\/code>. So adding “darling” to the list of names the wife can use also adds it to the intern’s vocabulary.<\/p>\n

If copy<\/code> was used instead, then each Person<\/code> would have their own separate list of names, insulated from changes to the temporary variable appropriateNames<\/code>.<\/p>\n

A Sneaky Bug Too<\/h3>\n

This is a particularly insidious problem in Foundation\/Cocoa, because mutable objects are subclasses of immutable objects. This means every NSMutableThing<\/code> is also a NSThing<\/code>. So even if a method is declared to take an immutable object, if someone passes in a mutable object by accident, there will be no compile-time or run-time warnings.<\/p>\n

Unfortunately, there isn’t a good way to enforce that a method takes an object, but not a subclass. Because Foundation makes heavy use of class clusters<\/a>, it’s very difficult to figure out if you have an immutable class, or it’s mutable subclass. For example, with:
\nNSArray *immutableArray = [NSArray array];
\nNSMutableArray *mutableArray = [NSMutableArray array];
<\/code><\/p>\n

[immutableArray isKindOfClass:[NSArray class]] is YES
\n[immutableArray isKindOfClass:[NSMutableArray class]] is YES
\n[mutableArray isKindOfClass:[NSArray class]] is YES
\n[mutableArray isKindOfClass:[NSMutableArray class]] is YES
\n[mutableArray isKindOfClass:[immutableArray class]] is YES
\n[immutableArray isKindOfClass:[mutableArray class]] is YES
<\/code><\/p><\/blockquote>\n

Sad, but true<\/code>.<\/p>\n

copy<\/code> Is Fast!<\/h3>\n

With nearly every immutable Foundation object, copy<\/code> and retain<\/code> are the same thing<\/strong> — there is absolutely no<\/em> penalty for using copy<\/code> over retain<\/code>! The only time you would take a performance hit using copy<\/code> would be if the object actually was mutable. And then you really do want to copy<\/code> it, to avoid bugs!<\/p>\n

The only exceptions I know of are: NSDate<\/code>, and NSAttributedString<\/code>.<\/p>\n

But don’t just take my word for it! Here’s the snippet of code I used to test all this:<\/p>\n

NSMutableArray *objects = [NSMutableArray array];
\n\/\/add anything that can be made with alloc\/init
\nNSArray *classNames = [NSArray arrayWithObjects:@\"NSArray\", @\"NSColor\", @\"NSData\", @\"NSDictionary\", @\"NSSet\", @\"NSString\", nil];
\nfor(NSString *className in classNames) {
\n   id obj = [[NSClassFromString(className) alloc] init];
\n   if(obj)
\n      [objects addObject:obj];
\n   else
\n      NSLog(@\"WARNING: Could not instatiate an object of class %@\", className);
\n}<\/p>\n

\/\/manually add objects that must be created in a unique way
\n[objects addObject:[[NSAttributedString alloc] initWithString:@\"\"]];
\n[objects addObject:[NSDate date]];
\n[objects addObject:[NSNumber numberWithInt:0]];
\n[objects addObject:[NSValue valueWithSize:NSZeroSize]];<\/p>\n

\/\/test if retain and copy do the same thing
\nfor(id obj in objects)
\n   if(obj != [obj copy])
\n      NSLog(@\"copy and retain are not equvalent for %@ objects\", [obj className]);
\n<\/code><\/p>\n

Best Practices<\/h3>\n

Get in the habit of using copy<\/code>, anytime you need to set<\/code> or initWith<\/code> something. In general, copy<\/code> is safer then retain<\/code>, so always prefer it.<\/p>\n

I believe it is best to try copy<\/code> first. If an object can not be copied, you will find out about it the first<\/em> time your code is executed. It will be trivial to substitute retain<\/code> for copy<\/code>. But it is much harder, and takes much longer, to discover that you should have been using copy<\/code> instead of retain<\/code>. <\/p>\n

Choose copy<\/code>, unless you have a measurable justification for using retain<\/code>.<\/p>\n

UPDATE 2009-11-10: Obj-C 2.0 blocks have some peculiarities<\/a>, <\/p>\n

For this reason, if you need to return a block from a function or method, you must [[block copy] autorelease]<\/code> it, not simply [[block retain] autorelease]<\/code> it.<\/p>\n<\/blockquote>\n","protected":false},"excerpt":{"rendered":"

(Almost) every time you use retain in Objective-C\/Cocoa, you really should be using copy. Using retain can introduce some subtle bugs, and copy is faster then you think… A Bug Waiting To Bite The problem with using retain to “take ownership” of an object is that someone else has a pointer to the same object, […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[18,6,5,4],"tags":[241,156,224],"class_list":["post-167","post","type-post","status-publish","format-standard","hentry","category-bug-bite","category-cocoa","category-objective-c","category-programming","tag-best-practices","tag-foundation","tag-memory-management"],"_links":{"self":[{"href":"https:\/\/vgable.com\/blog\/wp-json\/wp\/v2\/posts\/167","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/vgable.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/vgable.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/vgable.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/vgable.com\/blog\/wp-json\/wp\/v2\/comments?post=167"}],"version-history":[{"count":2,"href":"https:\/\/vgable.com\/blog\/wp-json\/wp\/v2\/posts\/167\/revisions"}],"predecessor-version":[{"id":494,"href":"https:\/\/vgable.com\/blog\/wp-json\/wp\/v2\/posts\/167\/revisions\/494"}],"wp:attachment":[{"href":"https:\/\/vgable.com\/blog\/wp-json\/wp\/v2\/media?parent=167"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/vgable.com\/blog\/wp-json\/wp\/v2\/categories?post=167"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/vgable.com\/blog\/wp-json\/wp\/v2\/tags?post=167"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}

A program must be correct before it can be made to run faster. And we have seen there is no performance penalty for copy<\/code> on most common objects. So it makes sense to try copy<\/code> first<\/em>, and then replace it with retain<\/code> if it proves to be necessary through measurement<\/em>. You will be measuring before you start “optimizing”, right? (I also suspect that if taking ownership of an object is a bottle-neck, then the right optimization is not to switch to retain<\/code>, but to find a way to use a mutable object, or an object pool<\/a>, to avoid the “take ownership” step altogether.)<\/p>\n