Re: Memory Management
Re: Memory Management
- Subject: Re: Memory Management
- From: Fritz Anderson <email@hidden>
- Date: Mon, 28 Jul 2003 16:51:33 -0500
On Monday, 28 July 2003, at 3:12 PM, Marcel Weiher wrote:
On Monday, Jul 28, 2003, at 20:50 Europe/London, Fritz Anderson wrote:
NSString * result = [myNamedObject name];
[myNamedObject release];
NSLog(@"The name was %@" result); // MPW wants an access exception
here.
I don't *want* an access exception here. However an access exception
is perfectly valid here, the code snippet you show is *obviously*
buggy.
You are not allowed to answer that I am _supposed to know_ how -name
is implemented.
EXACTLY, but this is precisely what you are doing when you access the
return value after its containing object is released. The only way to
NOT make this assumption is to retain the result yourself when you
release the container.
You are no stranger to the concept of "object orientation." It allows
us to rely on the behavior and state of programming constructs _without
reference to their implementation_.
In my mind's ear, I hear you saying, in shocked tones, that I am
"access[ing] the return value after its containing object is released."
But that requires one to know that what-name-returns is "contained" (in
some sense which can only boil down to implementation details) and not
"computed." When I said you were not allowed to answer along those
lines, I was restricting you from making implementation-specific
arguments. Who told you that "the return value" of -name _has_ a
"containing object" at all?
I suppose your answer must be that "containing object" is a red
herring, and that -name's return must be retained regardless of how it
might be implemented.
When I said I felt entitled to the assumption that returned NSObject
*'s had at least autorelease lifetimes, I was stating what I believed
was a reasonable contract, and one that I had seen violated only once.
I also assume that a class's -description method will return an
NSString *; not all assumptions are unreasonable.
You make a different assumption: That Cocoa memory is a roiling
cauldron of ephemera, and that everything -- including, I suppose, the
results of convenience constructors -- must be nailed down with
-retains immediately, lest they be snatched away in the whirlwind.
Because you have no rigorous way of knowing the "containing object," if
any, of anything, do you? Any -release could bring the whole house of
cards down. I don't think I'm being unfair to you, here: You have
argued that when I send [obj release], objects that depend on obj may
become invalid; I don't think you have a way to stop short of fearing
that _any_ nonretained object may become invalid. O-O principles bar
you from saying what object may or may not depend on another.
Personally, I think that's no way to live. Having most simple-object
accessors return [[member retain] autorelease] is a very small price to
pay for very large degree of civilization: The programmer need only
consider two classes of memory lifetimes, autorelease'd and alloc'ed,
and can be certain that anything not returned from alloc/copy/new is of
autorelease lifetime. The third class, for which you have to guess at
whether you must be paranoid (in principle anything not
alloc/copy/new), goes away.
Note well that most tutorial documentation _encourages_ newcomers to
think in terms of only two classes of memory retention.
You mention items in collections as a counterexample. Good
counterexample.
First, the non-retain/autorelease behavior is documented _extensively._
I'm not religious about [[ retain] autorelease]; if you want to commit
to an implementation in the documentation and warn that returned values
have the recipient's lifetime, you've done you're job. If you can show
your program is spending most of its time in -retain, or thrashing in
an overfull autorelease pool, by all means use a direct accessor, but
document it.
Second, the memory management of the collection classes would be a
better example if it were so blindingly obvious and intuitive that it
didn't _need_ extensive documentation as an difficult case. The fact is
that users have to be drilled in a particular mental model of what goes
on in those classes before it becomes "obvious" that the return value
of -objectAtIndex: should be retained if you want to dispose of the
container. Such drill (and hours of trial-and-error) is to be expected
for NSArray and NSMutableArray. I guarantee you that users will not
(should not) forgive that kind of abuse from less carefully-studied
classes beginning with FA, or even (the excellent) MPW.
-- F
_______________________________________________
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.