3 ms·
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. Bu
by 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 agoPeople 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 agoHere'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 16y agoUIPopoverController 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.
- seanalltogether 16y agoPrecisely, and that's the thing I've come to learn about objective-c memory management. It's fairly easy to learn as the article points out, but in practice when you have to interface with other developers code, it can be a confusing mess.
- andolanra 16y agoI know this from practice, having come in halfway through a project on iOS whose code was exquisitely, terrifyingly awful. I was fine on memory management; it was hunting down previous memory management errors that took up most of my time. I ended up giving up and reimplementing certain classes because it was seriously simpler than debugging the existing code. I think the issue is that trivial examples—for example, the kind you have in a blog post or comment—will invariably look simple and easy. In a non-trivial application, "four basic rules" ends up being four more things that can create bugs.
- 16y ago