Mailing Lists: Apple Mailing Lists
Image of Mac OS face in stamp
 
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Memory Management

On Wednesday, July 30, 2003, at 09:23 PM, Marcel Weiher wrote:


I am not promoting the use of retain] autorelease] (I dislike slowness :)), but I don't mind it to be the documentation default.

I do.

1) It creates more problems than it solves (masking/delaying erros until the autorelease pool pops)

I think this is the #1 problem with using autorelease excessively.

2) The problem it 'solves' is exceedingly rare in practice
3) It actually doesn't even 'solve' that, because important cases are exceptions (collections, 'performance critical' code)

Agreed.

4) The real solution in those exceedingly rare cases that need it is trivial: let the caller retain
5) Having the retain in the calling code makes it intention revealing, showing what you actually wanted to do at that point
6) Due to (4) it complicates the rules instead of simplifying them

I agree very much with this. I've been programming Cocoa for about 7-8 months now and when I first ran across an accessor returning a string, my FIRST instinct was that I should retain it, especially if I'm getting rid of the object I got it from.

My understanding of the Cocoa memory management is summed up very simply: If you alloc an object, you are responsible for releasing it. If you get an object from any other method such as class methods that return some instance of the object or accessor methods then you must retain it if you expect it to be around for any length of time.

The bottom line is, code defensively. If you are unsure of object lifetime, then retain it! Never assume that it's been autoreleased and won't go away until the pool is popped, and likewise never assume it'll be valid until the object you got it from is destroyed because for all you know, it could be autoreleased and will go away when the pool is popped. Assume that either may be the case, and code accordingly.

Coding in any variant of C, whether that be plain C, Objective-C, C++ or Objective-C++ demands defensive programming techniques. Wherever there is doubt in your mind, err on the side of caution. This is illustrated quite clearly by the problem at hand where the code appears to work for a while, but under slightly different circumstances it crashes the program.

7) It also complicates object lifetimes / the object ownership rules
8) It creates expectations of "safety" that an imperative language can never fulfill
9) The cases where it applies are cases where you need to think about your sharing semantics anyhow (see 5)
10) The performance cost (factor 10) is quite significant, and non-localized
11) KISS says: just say no! ;-)

That being said, I have no problem with it being listed as an option, and people deciding what they want to do. However, I do have a problem with it being listed as the default, most of all because of (8. Each time this subject comes up and more and more really smart people fall into similar traps about the 'safety' of the technique convinces me more and more that there is a real problem.

Right. I try to minimize the use of autorelease in my code. I consider autorelease to be very useful when returning an object from a function (that is its official purpose after all) and am leery of using it otherwise. It can add needless complexity by leaving you wondering when the object will get released. A simple release at the appropriate time would guarantee you have no more rights to use that object.

Having missed all previous discussions on doing [[object retain] autorelease] I'll be brief and just say that my first instinct told me that doing that could surely lead to harder to find bugs later on. Judging from what little discussion I've now read, it seems my instincts are spot on.

-Dave
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.
References: 
 >Re: Memory Management (From: Marcel Weiher <email@hidden>)



Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2007 Apple Inc. All rights reserved.