Re: how to create a NSMenuItem without memory leaks
Re: how to create a NSMenuItem without memory leaks
- Subject: Re: how to create a NSMenuItem without memory leaks
- From: Conrad Shultz <email@hidden>
- Date: Mon, 16 May 2011 17:16:02 -0700
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 5/16/11 4:44 PM, Martin Batholdy wrote:
> Is this how you would do it properly:
>
> newItem = [[NSMenuItem alloc] initWithTitle:aTitle action:@selector(show:) keyEquivalent:@""];
>
> [menu addItem:newItem];
> // with the addItem command newItem gets retained by 1. So I can release it:
>
> [newItem release];
Much better, but try to think in terms of ownership, not retain counts.
If you need something to stick around, take ownership: -retain it (or
- -init, -copy, etc., per the rules Nick sent you to). When you are
finished, -release it (relinquish ownership).
If you start thinking in terms of retain counts you run the risk of
trying to interpret -retainCount as a number that is somehow useful.
(It's not, for a reasonable definition of "useful.) Worse, you might
try to use strategic -retain and -release calls to shim the retain count
to what you expect (don't do this).
Just beat the memory management rules into your head and follow them
assiduously. Trust that NSObject is managing the retain count for you
properly.
So, in the case above, if you needed to access newItem later on, don't
release it (yet). Release it when you are finished. In the case of
ivars, this means retaining when the ivar is set and releasing in
- -dealloc (and not ignoring XCode's warning that you failed to call
[super dealloc]... you'll get my reference in the future if you don't
already).
> and [menu removeItemAtIndex: x]; should destroy the object newItem points to because the retain count decreases to 0.
Or, restated, trust that -removeItemAtIndex: will obey its contract with
you vis-a-vis memory management and that the object will go away at an
appropriate time.
Note that, in general, deallocation does NOT nil out the object. So at
some point you will inevitably crash with the infamous EXC_BAD_ACCESS,
which almost certainly means that you tried to send a message to an
object that has been deallocated. Just wanted to let you know this in
advance so you have somewhere to start when you run into this.
Finally, when you think you finally understand the rules, run your
application through Leaks and make liberal use of the heapshot tool to
understand what's going on. Fixing the leaks will do wonders for
cementing your understanding. Bill Bumgarner has a nice post on this point:
http://www.friday.com/bbum/2010/10/17/when-is-a-leak-not-a-leak-using-heapshot-analysis-to-find-undesirable-memory-growth/
- --
Conrad Shultz
Synthetiq Solutions
www.synthetiqsolutions.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iD8DBQFN0b5CaOlrz5+0JdURAi64AJ4js6ieIlie9s3l+O08XV0ieLH/swCeMmIW
KUeZExnh6PDj7esTklHdS9I=
=nFPf
-----END PGP SIGNATURE-----
_______________________________________________
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