Objective-C Memory Management For Lazy People

http://interfacelab.com/objective-c-memory-management-for-lazy-people/

by jawngee • 16 years ago

96 35 16 years ago

statictype• 16 years ago

This article has some good points for people who are new to Objective-C, but (much like the comments you complained that people were downvoting) the snarkiness and condescension tends to distract from it.

Anyway, thanks for posting it. FWIW, I'm one of the comments you linked to as being unhelpful.

chime• 16 years ago

> @property (retain) NSString *title;

Why is he retaining NSString? Shouldn't that be (copy)?

msbarnett• 16 years ago

Not necessarily. If you want to avoid situations where title points at a mutable subclass, yes, but if that isn't a concern, there's nothing inherently incorrect with a simple retain.

ajg1977• 16 years ago

Except that if someone modifies the string they passed you, your 'copy' of the string will also change.

jckarter• 16 years ago

"copy"ing an immutable string just retains it, so there's little benefit to using a retain property for NSString properties, or for properties of the other NSMutableCopying type families. As a best practice you should always use copy properties for them.

blub3• 16 years ago

Well, before knowing about Obj-C memory management in detail I thought it was ok. Now that I know the rules it looks painful.

If someone were to write such an article about C, then it would have just one line: if you malloc, then you must free.

If someone were to write such an article about C++, it would be more involved: delete if you new, delete[] if you new[] and then they'd explain auto_ptr and shared_ptr. More complicated that C, but still reasonably easy and you can get automatic memory management.

On the other hand we have Objective-C, where you apparently need at least 11 paragraphs to explain the basics, only to find out that - yes - you still have to call malloc and free only with other names and slightly different behaviour?

rimantas• 16 years ago

A car is a horse only with other name and different behavior.

If you new, alloc or copy, you own the object and must release it. Don't take ownership of delegates. That's about it.

btn• 16 years ago

The article is written in a condescending manner because the author is irritated. This means that it drags on a bit because of all the hand-holding through mundane examples.

The rules are just as simple as C or C++, and Apple explains them far more succinctly:

http://developer.apple.com/library/mac/#documentation/Cocoa/...

blub3• 16 years ago

I don't mind that the author is condescending. However, I do not understand why C memory management is widely considered as difficult (there's a big trend to support GC nowadays to escape the "evil of malloc"), but Obj-C memory management is considered by the author as easy.

dominostars3• 16 years ago

The article complicates things by talking about 'autorelease' and '@property'. Neither of these concepts are necessary in understanding memory management in ObjC, they just add convenience to it.

jonhendry• 16 years ago

There are many, many methods that return autoreleased objects, which must be retained if you don't want your app to go boom, so I'd argue that autorelease should be covered. At least to the extent of explaining this.

autorelease was added at the same time as the retain/release. @property, on the other hand, came much, much later and is entirely separate.

pornel• 16 years ago

For me "if you malloc, then you must free" is much harder, because you have to know whether ownership was passed to you, who else might be using object when you free it, etc.

In Objective-C there's no owner, everyone borrows objects. You increase retain count (if you want to hold object for longer than lifetime of a function), and you decrease retain count when done.

And there are few methods to increase (retain, init, copy, new, property assignent) and few to decrease count (release, autorelease, nil property assignment).

To me it's that simple.

schumihan2• 16 years ago

Reference count based GC? How would you deal with circular reference?

tzs• 16 years ago

> If someone were to write such an article about C, then it would have just one line: if you malloc, then you must free.

That implies you cannot return malloc'ed memory to a caller in C. I doubt many people are willing to live under that restriction.

Xuzz• 16 years ago

Many C APIs do exactly that: they require you (the caller) to malloc your own memory, then pass in a pointer.

dgallagher• 16 years ago

The author didn't do a clear job explaining Obj-C's memory management. Apple on the other hand does:

http://developer.apple.com/library/mac/#documentation/Cocoa/...

--------------------

In simplistic form:

A) If a method "begins with" alloc or new, you must release or autorelease.

B) If a method "contains" copy, you must release or autorelease.

C) For every retain message you send to an object, you must balance it out with a release or autorelease (e.g. malloc/free).

D) If a method returns an object to you, and the method name did not match with the "A" or "B" rules, you have received an autoreleased object. This object is guaranteed to exist for the remainder of its identifier's scope.

E) To make an autoreleased object live longer than its identifier's scope, retain it (ensuring to release/autorelease it when finished).

--------------------

There are a few edge scenario's too (described in the link), but that's the gist of it. Also, whenever you put an object inside an NSSet/NSArray/NSDictionary, it's sent a retain message. When said NSSet/NSArray/NSDictionary gets deallocated, it sends a "release" message to all of its members. A lot of other objects act similarly (always documented well by Apple).

At first it's a little challenging to grasp. But after programming for a little while in Obj-C using the Foundation or Cocoa API, you get the hang of it and it comes quite naturally.

In general I've found learning Obj-C with Foundation/Cocoa is difficult at first, mostly from trying to grasp the design patterns Apple has used with OOP. For example, delegate methods, bindings (using KVC/KVO), the responder chain, etc... But after you've learned them, you go "ah ha!!!" and get it. Then things become much easier to code.

On top of that, I have nothing but good things to say about other Apple coders. From bloggers, to StackOverflow users, to IRC; everybody is extremely helpful and pleasant to deal with. :)

vasi• 16 years ago

I think the article vastly overstates its case. Nobody disputes that it's possible to have more-or-less working memory management in ref-counted Objective-C. But it's clearly harder than in a GC language, else it wouldn't need seven pages worth of "simple rules" to explain.

Moreover, the author glosses over many of subtleties of reference-counting. For example, accessors in Java are dead-simple, practically boilerplate. But in Cocoa, what looks like a perfectly reasonable implementation to a newcomer is in fact buggy:

  - setFoo: (id)aFoo {
    [foo release];
    foo = [aFoo retain];
  }

Look closely, and you'll realize that if foo and aFoo are in fact the same object, it will be freed, and foo will have an invalid pointer assigned to it. Pretty much every Cocoa programmer knows about this, but we shouldn't ahve to.

One of the better Cocoa blogs is written by Mike Ash, and he has quite a few posts that illustrate some of these issues. For example, the first half of http://www.mikeash.com/pyblog/friday-qa-2010-12-03-accessors... talks about whether or not accessors should autorelease their return values, with pros and cons for each option. Later on, the money quote: "If you're using garbage collection, this whole question becomes vastly simpler."

Our author here says that "Cyclic object graphs in Objective-C are not a problem. At all." But another post by Mike Ash illustrates that it can be harder to deal with: http://www.mikeash.com/pyblog/friday-qa-2010-04-30-dealing-w... . A great example:

  _myInstanceVar = [[SomeClass alloc] initWithBlock: ^{
    [self doSomething];
  }];

Using 'self' within the block captures it in the closure as a reference, and then the closure itself is referred to by the instance variable of 'self'. This cycle is hard for the coder to notice, and will leak.

joubert• 16 years ago

People should really use @property syntax for accessors, unless they need finer control over what happens. http://developer.apple.com/library/mac/#documentation/Cocoa/...

seanalltogether2• 16 years ago

Here's another good example of why memory management isn't as simple as this article makes it out to be

    -(void) addAccount:(UIBarButtonItem*)button {
        ListController *list = [[ListController alloc] initWithStyle:UITableViewStylePlain];
        UIPopoverController *pop = [[UIPopoverController alloc] initWithContentViewController:list];
        pop.popoverContentSize = CGSizeMake(320, 200);
        [pop presentPopoverFromBarButtonItem:button permittedArrowDirections:UIPopoverArrowDirectionAny animated:YES];
        [list release];
        [pop release];
    }

Anyone see the problem with this code?

rbritton• 16 years ago

UIPopoverController does not retain itself and will cause a crash shortly after that release. Both the iOS SDK and the Cocoa SDK are fairly inconsistent about which presentation classes require retaining and which handle that themselves -- UIAlertView does not require it, for example.

alexyoung• 16 years ago

The reason most people find Objective-C memory management hard at first is they don't realise the importance of recognising and following the conventions.

Once you know the handful of conventions the article covers, knowing when to retain or release is pretty easy.

wzdd• 16 years ago

The original article was strange in that it got a whole lot of things wrong, but was sufficiently technical that you would actually have to have been an iOS and an Android developer in order to discuss it. This is why the comments were so content-free on Hacker News.

(Just one example of the things the article got wrong: The Android emulator actually defers a lot to the host OS and its own implementations to the point where I have never seen an OpenGL ES app that runs the same way on the emulator as it does on real hardware; the Android emulator also runs at full speed: it's just slower because it's doing more.)

Objective-C Memory Management For Lazy People

Related Stories