-----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 (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
