Re: [[object autorelease] release]
Re: [[object autorelease] release]
- Subject: Re: [[object autorelease] release]
- From: Brant Vasilieff <email@hidden>
- Date: Tue, 2 Oct 2001 11:17:25 -0700
On Tuesday, October 2, 2001, at 04:47 AM, Markus Hitter <mah@jump-
ing.de> wrote:
The situations might be rare, I agree. But as ...release] would
find out itsself wether the object is already autoreleased, this
wouldn't require an addition to the API .
An object doesn't know if it's been autoreleased. It only has a retain
count. If five objects all share ownership in an object, i.e. someone
created it with a call to alloc or copy, and the others have called
retain, then the retain count will be five. Among the owners, it's
impossible to tell which of them have called autorelease and which have
called release on the object when they no longer needed it.
Autoreleased isn't a state that an object is in or a property of the
object. An autorelease pool, is simply a delay que for a call to
release. An object could reside in many autorelease pools. It's also
quite common for an object to reside multiple times in the same pool.
So, to avoid huge collections of autoreleased and no longer
needed objects, it might make sense to add a "flush" method to
NSAutoreleasePool which would free all objects with retain count
already zero but would NOT decrement the retain count. This
would avoid easily these nested pools, which appear a little
ugly (at least to me).
If you were to add a flush method, it wouldn't be responsible for
freeing any objects, just calling release on them. The objects
themselves are responsible for deallocating themselves when their retain
count reaches zero.
But flush would be a very dangerous method to include, as it would
release all objects in the pool, even those still in use further up the
call stack. If you want to prevent huge pools, create your own pool
within the loop. That way only those objects created locally within the
pool will be released.
Cheers,
Brant