Re: menu madness with retain count
Re: menu madness with retain count
- Subject: Re: menu madness with retain count
- From: Shawn Erickson <email@hidden>
- Date: Tue, 27 Apr 2010 14:08:09 -0700
On Tue, Apr 27, 2010 at 1:49 PM, Bill Appleton
<email@hidden> wrote:
>>> 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
The retain count is accurate and it is tested on the "final" release
to make the decision about deallocating the object.
What isn't useful about retain count it trying to poke at the value at
any given point in time and trying to make sense of why the count is a
particular value. The Cocoa framework, etc. can retain and
release/autorelease objects that you use as you use them with various
framework APIs. When and what it does in an implementation detail that
easily changes between OS released, etc.. Also the retain count
doesn't reflect any pending autoreleases.
If you want to evaluate object life cycle issues you should use
Instruments (Object Allocations, Zombies, and/or Leaks templates).
Using Instruments you can get timeline of retain / release /
autorelease messages sent to a given object.
You can expect the framework and any properly written code to retain
objects as needed to ensure they live as long as needed. When no
longer needed they will release/auotorelease their "claim" on the
object (balance any retains they sent to establish a "claim").
One of the biggest problem folks have when first getting into Cocoa
development is over thinking memory management... it truly is simple
and the core memory management model is follow pervasively in all
frameworks provide by Apple and third parties.
-Shawn
_______________________________________________
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