7 ms·

Objective-C Memory Management For Lazy People

96 points by jawngee 16y ago

statictype 16y 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 16y ago
> @property (retain) NSString *title; Why is he retaining NSString? Shouldn't that be (copy)?
- msbarnett 16y 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 16y ago
    Except that if someone modifies the string they passed you, your 'copy' of the string will also change.
    - naz 16y ago
      That would only occur if it was an NSMutableString, like the GP said.
  - jckarter 16y 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.
blub 16y 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 16y 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 16y 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/Conceptual/MemoryMgmt/Articles/mmRules.html http://developer.apple.com/library/mac/#documentation/Cocoa/...
  - blub 16y 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.
    - stuhacking 16y ago
      Objective-C memory management is still an abstract concept that has, as the root of it's mechanism, objects. You create an object, you release an object. C's memory management has a simplistic interface: malloc/free. However it operates on the notion of raw memory space. You need to do more work figuring out how much memory you need based on the size of your objects. C's memory management is not difficult, but it is more involved. The author says it pretty well when he states that Obj-C hits a middle ground between GC and manual memory management. It elevates the control of memory to a level where it makes more contextual sense.
vasi 16y 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-memory-management-and-thread-safety.html 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-with-retain-cycles.html 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 16y 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/Conceptual/ObjectiveC/Articles/ocProperties.html http://developer.apple.com/library/mac/#documentation/Cocoa/...
- seanalltogether 16y 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?
alexyoung 16y 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 16y 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.)

96 points by jawngee 16y 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 16y ago

> @property (retain) NSString *title; Why is he retaining NSString? Shouldn't that be (copy)?

msbarnett 16y 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 16y ago
  Except that if someone modifies the string they passed you, your 'copy' of the string will also change.
  - naz 16y ago
    That would only occur if it was an NSMutableString, like the GP said.
- jckarter 16y 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.

blub 16y 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 16y 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 16y 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/Conceptual/MemoryMgmt/Articles/mmRules.html http://developer.apple.com/library/mac/#documentation/Cocoa/...
- blub 16y 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.
  - stuhacking 16y ago
    Objective-C memory management is still an abstract concept that has, as the root of it's mechanism, objects. You create an object, you release an object. C's memory management has a simplistic interface: malloc/free. However it operates on the notion of raw memory space. You need to do more work figuring out how much memory you need based on the size of your objects. C's memory management is not difficult, but it is more involved. The author says it pretty well when he states that Obj-C hits a middle ground between GC and manual memory management. It elevates the control of memory to a level where it makes more contextual sense.

vasi 16y 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-memory-management-and-thread-safety.html 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-with-retain-cycles.html 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 16y 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/Conceptual/ObjectiveC/Articles/ocProperties.html http://developer.apple.com/library/mac/#documentation/Cocoa/...
seanalltogether 16y 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?

alexyoung 16y 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 16y 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.)