Re: NSMutableString question
Re: NSMutableString question
- Subject: Re: NSMutableString question
- From: Jason Coco <email@hidden>
- Date: Wed, 17 Sep 2008 13:32:58 -0400
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
Attachment:
smime.p7s
Description: S/MIME cryptographic 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