Re: Memory Management
Re: Memory Management
- Subject: Re: Memory Management
- From: David Elliott <email@hidden>
- Date: Thu, 31 Jul 2003 09:56:12 -0400
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.