Re: Memory Management
Re: Memory Management
- Subject: Re: Memory Management
- From: Marco Scheurer <email@hidden>
- Date: Wed, 30 Jul 2003 00:40:08 +0200
On Tuesday, July 29, 2003, at 08:23 PM, Nat! wrote:
Am Dienstag, 29.07.03 um 17:01 Uhr schrieb Marco Scheurer:
On Monday, July 28, 2003, at 09:50 PM, Fritz Anderson wrote:
You surprise me. I once ran into a string-processing method in
OmniFoundation which, in no-op cases, returned its internal storage.
Consider the following code:
NSString * result = [ofProcessingObject processedString];
[ofProcessObject release];
NSLog(@"The result is %@", result);
I am entitled to assume that result has not been disposed-of, am I
not?
I share Marcel's views on this subject. We wrote an article which
shows why we think that this pattern is a bad thing. It will
hopefully be published soon.
This pattern is obviously an attempt to fix in -processedString a
problem that is caused by = .
The problem is not caused by =.
[...]
What I'd like to add is this. Sharing a return value between caller
and method
This's what I meant by saying that the problem was caused by =.
ideally should be fail safe. To be fail safe the returned value must
be under ownership of the caller. With ownership I mean, that the
value can be read (or written to, if possible) at the callers
convenience. [...]
I am sharing ownership with the caller. (If name_ is immutable, I am
sharing read access completely.) This would be the proper thing to do,
alas it is not Foundation like, because the need for the caller to
release all accessed objects would also be too painful to code. The
Foundation way to achieve almost fail safeness is to provide the
caller with [... retain] autorelease] a return value, which gives full
read access during the scope of the callers(!) autorelease pool.
Agreed, but it is of limted interest since the value still cannot be
read at the caller's convenience: it is limited to this scope. This is
what I wanted to illustrate with the two examples.
[...]
I am not promoting the use of retain] autorelease] (I dislike slowness
:)),
Yes, it's slow, but it wouldn't be such a problem if it could be easily
detected in profiling and fixed. However, spreading retain]
autorelease] in your code will result in profiles where you can see
time spent in autorelease pool management, and it's hard to tell which
accessors are responsible if any. And if you find that one is a
problem, you may be unable to fix it because client code, not
necessarily yours, could break.
but I don't mind it to be the documentation default. What I dislike is
the dogmatic "you must code like this". Fortunately I see nothing like
this in the Apple dox.
Good. I still haven't read the latest, "xcode", version of the doc.
There is still a problem if one needs to read the doc for every
accessor, however trivial, to know if it is of one kind or another. The
previous guideline (you, the caller, must take responsibility and
retain) was a real standard and therefore much better.
(And BTW, I was certainly not advocating garbage collection).
marco
Marco Scheurer
Sen:te, Lausanne, Switzerland
http://www.sente.ch
_______________________________________________
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.