Re: menu madness with retain count
Re: menu madness with retain count
- Subject: Re: menu madness with retain count
- From: Bill Appleton <email@hidden>
- Date: Tue, 27 Apr 2010 13:49:53 -0700
>> Over the years, I think that looking at the retain count is the #1 cause
of hairpulling on this list.
it's too bad this is unreliable
an object should be able to return this info
and it isn't simple, it gets convoluted in process
if i add a submenu to an item then it is retained by the menu
but then if i then set that submenu to nil is it still retained?
if retained count was accurate you could test it on final release, etc
On Tue, Apr 27, 2010 at 12:53 PM, Steve Bird <email@hidden> wrote:
>
> On Apr 27, 2010, at 3:38 PM, vincent habchi wrote:
>
> > Le 27 avr. 2010 à 21:21, Scott Ribe a écrit :
> >
> >>> 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?
> >>
> >> Why would you care?
> >
> > Because earlier in this afternoon I decided to trace the retain/release
> messages sent to an object by overriding the respective methods and have
> them write the retain count before calling super methods. I registered most
> curious behaviors, for example objects released while the last time their
> retain count was printed it was equal to 2. No 1, no 0. That's why I asked,
> just to know if autorelease does not short-circuit the traditional release:
> call by accessing the retain count directly.
>
> --- It can't. It simply sends a release message at some future time. Its
> purpose is to delay the actual release long enough for me to create an
> object and hand it to you, my caller.
>
> If I create this object, I cannot release it before I return to you - the
> object would disappear. But if I don't ever release it, then it will never
> disappear. So I autorelease it, and return it to you.
>
> If you want to keep it around, then YOU retain it yourself, and release it
> when you see fit. If you don't, then do nothing.
>
> The fact that it's in the autorelease pool simply means it gets a release
> message at some point in the near future. No more, no less. If you've
> retained the object I gave you then this release does nothing noticeable.
> If you haven't, then this release deallocates the object.
>
> I'll say it again: being in the autorelease pool simply means you will get
> one release message when the runtime gets around to it.
> If you are in the pool TWICE, you will get TWO release messages when the
> runtime gets around to it.
>
> Over the years, I think that looking at the retain count is the #1 cause of
> hairpulling on this list.
> ----------------------------------------------------------------
> Steve Bird
> Culverson Software - Elegant software that is a pleasure to use.
> www.Culverson.com (toll free) 1-877-676-8175
>
>
> _______________________________________________
>
> 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
>
_______________________________________________
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