On Sep 17, 2008, at 12:08 , Roland King wrote:
You'd think perhaps that alloc/init would give you an object which really has never been retained by anyone else, but as I said I remembered a post from a while ago about a complex object which was alloc/init'ed but ended up still having a retain/autorelease on it, so it hung around after the author of that post thought it would be gone.
That must be a really rare case. Do you remember if this was from one of the Cocoa framework objects or rather from something that somebody else created? I can't think of any reason why you would want to [[self retain] autorelease] from within init unless you didn't really know how the whole Cocoa memory management/ownership/reference counting system worked when you wrote your initializer. (BTW, when I say you here, I don't mean you, Roland :-) I mean the generic you).
I've had cases where I've released the allocated object self within my init and created a new object, but that object leaves init with only one reference to it... I think that's kinda the implied contract, although if it was autoreleased, it still will be freed at some future point and won't be leaked.
You can never actually totally manage when an object is really, actually deallocated. Implementation details mean that objects could have retains on them (either real or from some outer autorelease pool you have no control over) but if you want to be aggressive about it and do all you can to maximize the chance objects are actually deallocated when you personally are done with them it seems to me that the worst of all worlds is the convenience constructor, in the middle is alloc/init, and the best shot you can give yourself is to make your own autorelease pool and retain/release all the objects you want inside it.
I think it depends on your situation. Like I said, I think that the second may be better if you have a tight loop that creates lots of little helper objects that you don't care anymore once the scope of the loop ends. However, in most cases if your alloc/init an object and own that object, when you release it, it is probably going to get deallocated. If you're really paranoid about memory, you can ask the object if anyone else has a reference to it (for debugging purposes) and try to track down who's holding it and re-thing your design so that you conserve more memory... but if somebody else /did/ take ownership of an object that you created, it's probably a bad idea to deallocate it out from under them anyway. It's not being leaked, in that case.
/jason
smime.p7s
Description: S/MIME cryptographic 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 [EMAIL PROTECTED]
