Making sure I understand release/retain correctly

Question

Let's say I do the following (foo starts out as some object):
[foo release];
// STUFF with foo
[foo retain];
As long as I'm not re-assigning foo, at the end of this I'll still have the same foo, right? I'm not risking losing foo during the //STUFF am I?
I guess I'm making sure that my understanding of release is correct. If I release foo, it doesn't actually go away until all handles on it are gone. In other words, foo would have to be assigned to some other object in the //STUFF, or foo would have to go out of scope in the //STUFF (and presumably have a new foo created) in order for the actual original foo object to be deleted, right?
Ok, edit for motivation, because that's kind of a dumb thing to want to do, right?
The reason I want to do this is that lets say I have the following switch statement:
switch (test)
case 1:
foo = [A alloc];
[foo inita];
break;
case 2:
foo = [B alloc];
[foo initb];
break;
case 3:
[foo setupc];
break;
case 4:
f = [D alloc];
[foo initd];
break;
It makes sense to release foo before the switch and retain it at then end. EXCEPT for case 3. So, I was thinking that if was safe to do what I proposed, it might make the code simpler.
Of course I can just put a release/retain pair around each alloc/init, but that's a lot of replicated code...
A [foo autorelease] and then the retain might just do the trick.
Message was edited by: Brian Postow

Answer 1

Brian Postow wrote:
Let's say I do the following (foo starts out as some object):
[foo release];
// STUFF with foo
[foo retain];
As long as I'm not re-assigning foo, at the end of this I'll still have the same foo, right? I'm not risking losing foo during the //STUFF am I?
There is no way to tell. If the retain count of foo was one just before the release, then all bets are off.
I guess I'm making sure that my understanding of release is correct. If I release foo, it doesn't actually go away until all handles on it are gone.
I'm not sure I understand your understanding. I wouldn't use a term like "handle" since that has a specific meaning that is different than "retain count". If you replace "handle" with "retain count", then you are correct.
In other words, foo would have to be assigned to some other object in the //STUFF, or foo would have to go out of scope in the //STUFF (and presumably have a new foo created) in order for the actual original foo object to be deleted, right?
I'm not sure what you are saying. Objective-C is not C++. A variable going out of scope means nothing in Objective-C. It isn't that complex. It keeps track of the number of times "retain" is called on the object (including the original, implicit "retain"). When the number of releases matches the number of retains, then the object is deallocated.
Ok, edit for motivation, because that's kind of a dumb thing to want to do, right?
The reason I want to do this is that lets say I have the following switch statement:
switch (test)
case 1:
foo = [A alloc];
[foo inita];
break;
case 2:
foo = [B alloc];
[foo initb];
break;
case 3:
[foo setupc];
break;
case 4:
f = [D alloc];
[foo initd];
break;
You don't want to do that. Alloc-init is a set of operations. You can't spit them up. The object that "alloc" returns may not necessarily be the same object that "init" returns. "Alloc" may just return a global proxy object to do something more clever during the init.