Forum

[rames44]

Originally Posted by Max

wow, thanks a lot, it's more clear

So I guess it will be like this:

-(void)doSomething
{
 SomeObject *obj = [[[SomeObject alloc] init] autorelease]; // count 1
 self.obj = obj; // count becomes 2

//( can put some additional code here)

} // count back to 1

and in second case:

-(void) logValue:(int)intValue
{
    NSLog(@"%@", [NSString stringWithFormat:@"%d", intValue]); // count 1

// (some additional code)
// value is still there somewhere with count 1

} // count becomes 0, value destroyed

is it correct?

That's a reasonable way of thinking about it, I suppose, but it's not QUITE accurate. Strictly, the decrementing of the count doesn't happen at the end of the method, but at the end of the event processing - the highest level call from the event loop into your code. For example, consider the following:

- (void) handleButtonPress {
  NSString *myString = [self getMyString:2];
  ...do something with myString...
}

- (NSString *) getMyString:(int)intVal {
 return [NSString stringWithFormat:@"%d", intValue];
}

Here "handleButtonPress" is wired up to be called when a button is pressed. So the sequence is (very loosely):

1. Event processor pulls the "button press" event off the event queue
2. Event processor sets up an autorelease pool
3. Event processor calls "handleButtonPress"
4. "handleButtonPress" calls "getMyString"
5. "getMyString" calls [NSString stringWithFormat]
6. [NSString stringWithFormat] creates a string (use count is now 1)
7. [NSString stringWithFormat] calls "autorelease", placing the string in the autorelease pool, then returns it to "getMyString"
8. "getMyString" now has the string with a use count of 1
9. "getMyString" returns the string to "handleButtonPress" (still has a use count of 1)
10. "handleButtonPress" fiddles with the string, but doesn't retain it
11. "handleButtonPress" returns back to the event processor code (use count on the string is still 1)
12. The Event Processor now releases the autorelease pool. The pool reacts to this by executing a "release" on every object that's been placed in the pool. As a result, the string's use count is decremented to 0, and, as a result, the string is dealloc'd.

You see the distinction, I'm sure - it's not leaving the method that created the string that causes the "autorelease" to be triggered, it's completing the entire handling of the individual event call, because at the end of that process, the event loop explicitly dumps the pool. The object remains valid from the time it's created until you return back out of your code back to the OS - only then is it autoreleased. Thus, this isn't like a destructor in C++ that gets triggered when an object goes out of scope - it's a mechanism supported by the language, but which has to be supported, in turn, by the code in the environment.

As one example of what I mean by that last sentence, if you create your own thread to do background work, you have to explicitly create an autorelease pool as one of your first steps, and then release the autorelease pool (which, in turn, causes all the contained objects to be released) before your thread ends. If you don't do this your code goes BOOM as soon as you create anything involving an autorelease, since there's no pool into which the object can be placed. (Autorelease pools are thread-specific.) In "normal code", the event processing loop is what takes care of setting up and tearing down the pools for you, so you're not really aware that this is going on.

Hopefully that didn't muddy the water too much, but I always think that understanding the "magic" is good in the long run.