Re: Memory Management (Part I)
Re: Memory Management (Part I)
- Subject: Re: Memory Management (Part I)
- From: "Alastair J.Houghton" <email@hidden>
- Date: Fri, 8 Aug 2003 09:41:16 +0100
On Friday, August 8, 2003, at 12:44 am, Nat! wrote:
Am Mittwoch, 06.08.03 um 11:55 Uhr schrieb Marcel Weiher:
Anyway, you can't be at all sure that even this isolated examples
achieves what you are thinking it does.
In your lofty kind of thinking you can't even be sure what [xxx
retain] does. retain could be calling release for that matter. Problem
is, nobody cares about this (except you). We are dealing with Cocoa
here and not with Obj-C abstract.
Actually rather a lot of people care about this (although I'm sure
we're all getting a bit tired of the argument). And Marcel *can* be
sure what [object retain] achieves because it has well-defined
semantics, although of course you cannot assume anything about how it
implements those semantics.
Anyway are you trying to make an argument for autorelease here ? :)
No. It is a reductio-ad-absurdum. In order for the logic for
retain] autorelease] to be valid, you actually have to bracket
*calls* to methods with these constructs as well.
Because I didn't get the original idea, I have no clue how to parse
your meta argument. How about a little code snippet to show what you
mean.
The point that Marcel is trying to make is that if you are returning an
object's properties or contained data using your "return [[obj retain]
autorelease]" paradigm, in order for objects to have consistent
lifetimes you would also need to do the same in other cases (for
example for method parameters), which is plainly ridiculous.
I have to say I agree wholeheartedly with what both Marcel and Marco
have been saying on this subject. The fact is that religiously writing
"return [[obj retain] autorelease]" doesn't gain you a great deal,
because it is normally obvious when you need to retain an object in
order to prevent it being released, and additionally in order for it to
be useful in the general case you must make assumptions about when the
containing autorelease pool is released. All of which hardly seems
worth slowing down (and complicating) all of the property accessors and
all accessors of contained objects, not to mention the fact that it's
harder to debug reference counting problems on objects that have been
autoreleased, because crashes etcetera are deferred until some
indefinite point in the future.
Far better just to retain object properties (or contained objects)
whose owner you are releasing, because that is the only situation where
the simpler scheme causes problems, and it is an *obvious* situation in
the code. I would also contend that people don't often write code like
that, because the fact that the lifetimes of properties and contained
objects are (unless they are explicitly retained) nested inside the
lifetime of their owner makes a great deal of sense... most real-world
objects behave in that fashion, after all (e.g. I have a red ball. I
can see just by looking that it is red, but if I get rid of it somehow
[perhaps by throwing it away] I will have to remember that it is red if
I might need to know that fact later on. The "remember" in the
previous sentence corresponds to the -retain I would have had to send a
property in Cocoa.)
Rather than continuing this argument any further (since it is plainly
going nowhere), could Marco and Marcel perhaps send you a copy of their
article on the subject so that you can read it and understand why they
do not believe that writing "return [[obj retain] autorelease]" is a
good idea?
Kind regards,
Alastair.
_______________________________________________
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.