Re: Retain/release objects in an array...
Re: Retain/release objects in an array...
- Subject: Re: Retain/release objects in an array...
- From: Matt Neuburg <email@hidden>
- Date: Wed, 24 Jul 2002 07:52:34 -0700
On Tue, 23 Jul 2002 22:27:54 -0700, Jiva DeVoe <email@hidden> said:
>
I'm unclear... If I return an objectEnumerator from an array in one of my
>
functions... Should I autorelease it
Just follow the rules. Did you obtain the objectEnumerator by saying "copy"
or "alloc"? No. Did you say "retain" to it? No. Then presume it is
autoreleased and will vanish when the current event loop comes to an end.
If that's acceptable to you, do nothing. If it isn't, then retain it now
and release it when you're done with it. Read "Hold Me Use Me Free Me" or
any of the other classic tutorials.
>
Also, if I get an object via objectAtIndex, should I retain that as well?
Same answer.
Look, let me just try to clear this up by jogging your thinking. You don't
"get" an object. You get a *pointer* to an object. The question is whether
that pointer will still be needed after the current event loop comes to an
end, and if so, whether the object will still be there or whether you'll be
pointing at garbage. Whether that happens is not a feature of the pointer
but of the object itself - it has a retain count, and it will vanish in a
puff of smoke, regardless of how many pointers there are to it, when and
only when its retain count reaches zero. All you're ever doing when you
play with retain and release is raising and lowering the retain count of an
object to which you have a pointer. (Autorelease is like release except
that it will lower the retain count of an object at some future time.)
So now just apply logic. If you're not going to be holding this pointer to
this object through the end of the current event loop and into another, and
if you're not going to do anything else that might cause this object's
retain count to be lowered to zero during *this* event loop, then you've
nothing to worry about. On the other hand, if you're worried, you can
retain it if you like, and then it is your responsibility to release or
autorelease it. But observe that even if you need this pointer to be valid
through the end of the event loop, there may *still* be no *need* to retain
it, if you happen to know that the array is not going anywhere, since the
array has *already* retained it - clearly the object is guaranteed to live
as long as the array contains it, since it would not do an array much good
if its contents vanished after the end of the event loop, would it?
Notice that you can also do great harm in this situation. The array is
trusting you when it hands you a pointer to one of its objects, not to
screw up its ownership of that object. If you were to release (or
autorelease) that object without also having retained it, that object might
well vanish, and the array would now be left holding a pointer to junk.
That's not nice (and will probably lead to a crash). So never release
anything that isn't yours to release.
Another thing to ask yourself, now that you understand that object
references are pointers, is whether you really want to be holding a pointer
to the *same* object as the array. You've got two pointers to one object.
That can be good and it can be bad. If you change the object, that change
will also happen in the object that's "in" the array, because there's only
one object (with two pointers to it - yours and the array's). Is that what
you want? If not, copy the object (and now it is your job to release the
copy).
So what's the moral? (1) Object references are pointers; what you're mainly
trying to avoid is a junk pointer. (2) Every object has a retain count in
and of itself, and if that count hits zero, all pointers to it are junk.
(3) Use the "car" rule: if you said "copy", "alloc", or "retain", you
incremented the retain count and it is your job to decrement it by saying
"[auto]release" - if you didn't, it is your job *not* to say it. m.
--
matt neuburg, phd = email@hidden,
http://www.tidbits.com/matt
pantes anthropoi tou eidenai oregontai phusei
Subscribe to TidBITS! It's free and smart.
http://www.tidbits.com/
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.