Question

Just when I thought I’ve understood this topic completely, I’m back to basics.

I have a method that instantiates an autoreleased object, using (for example) stringWithFormat:

return [NSString stringWithFormat:@"what"];

Then I call this method from another method, and another method, each time returning this autoreleased NSString and in each level of the hierarchy. The code works fine and the NSString instance is intact at each level of the hierarchy.

I thought that since the instance is autoreleased, it could suddenly end up with a retainCount of 0 at any point in the call stack (i.e., one of the methods would be working on a released object). Is it true that I cannot depend on this object?

Edit: I realize the question wasn’t too clear. Sorry. I mean:

Method1 ---calls--->    Method2 ---calls---> Method3 ---instantiates the string---> 

Answer 1

It is safe to assume that an autoreleased object will not be deallocated in a stack frame below the frame in which it was allocated. So, in a call stack like

method1
  method2 <== instance allocated/autoreleased here
   method3 <== safe to use here

it is safe to assume an instance alloc/autoreleased in method2 is valid in method3 unless you play nasty tricks and drain a pool created in method1 from method3. This is because an autorelease pool in a higher frame cannot be drained (unless by stupidness) in a lower frame. Of course, once control returns to method1, all bets are off.

Autorelease pools alloc’d in a lower frame will not contain the instance autoreleased in method2 because they could not have been the active pool (they weren’t created yet!) at the time of the autorelease.

Finally, unless a method lower in the call chain, between the method of interest and the method that instantiates and autoreleases an object instance creates and drains an autorelease pool, you are assured that the enclosing pool will not be drained until the end of the run loop.