Re: menu madness with retain count
Re: menu madness with retain count
- Subject: Re: menu madness with retain count
- From: Jens Alfke <email@hidden>
- Date: Tue, 27 Apr 2010 12:17:12 -0700
On Apr 27, 2010, at 11:58 AM, vincent habchi wrote:
Yet, at the same time, you may want the dealloc: method to trigger
some events. For example, if you have a CALayer that holds various
sublayers, and that CALayer goes away, you may want all the
sublayers to go away at the same time. Yet, this is impossible if
some other object around locks a reference to the sublayers.
Most of the time you just want your -dealloc method to call -release
on objects it holds references to. Or you might need to clean up some
external resource (like closing a file), although it's often better to
have an explicit -close method on your class to do this.
In your example, it doesn't matter if the sub-layers stay around,
because they won't have a parent layer so won't be visible or consume
any graphics resources. If you somehow forced those sub-layers to get
dealloced at the same time as the parent layer, then any other object
that had a reference to one would crash the next time it accessed it;
bad news.
Remember that in a ref-counted (or GC'd) system you can't force an
object to deallocate (even 'self'.) The deallocation is under control
of all the other objects that have references, and the runtime itself.
So you should never put any code into -dealloc or -finalize that
absolutely has to run at a particular time.
By the way, how are exactly multiple calls to [object autorelease]
handled by the pool? Does this give rise to as many calls to
release: as they are autorelease references stored, or does the pool
directly adjust the retain count?
Each call to -autorelease will cause one future -release call. So yes,
the pool keeps a count of how many times -autorelease has been called
for each object, and calls -release on it that many times when it
drains.
—Jens_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden