Re: bogus retain via NSEnumerator

[John C. Randolph]

Wayne Cochran wrote:
> 
> David Stes <stes@D5E02AFE.kabel.telenet.be> wrote in message 
> news:<LS7gc.74513$_64.4972674@phobos.telenet-ops.be>...
> > In comp.lang.objective-c Wayne Cochran <wcochran@acm.org> wrote:
> > >
> > > Note the extra retain count on object 3.
> > > What's going on here?
> > >
> > > Note that this program behaves as expected under GNUstep on my Linux box.
> >
> >  The retain/release memory is so badly designed that it behaves different
> > on various operating systems.
> 
> The Cocoa version of autorelease and the one documented in
> the O'Reilly "Objective-C Pocket Reference" differ greatly.  I like the idea
> of autorelease sending a release message to the object as soon
> as the callee's stack frame is destroyed -- that makes a lot sense
> and is consistent with how local object's (i.e. stack
> allocated) are deallocated in C++.

You're missing the purpose of autorelease.  It's there specifically for
the case where you *don't* want the object to go away immediately,
although you are done with it yourself.  Sending -autorelease delays the
release, allowing others to -retain the object if they need to.  

Consider for example, the -stringByAppendingString: method of NSString. 
-stringByAppendingString: allocates a new string, but leaves it up to
the sender to decide whether it should live beyond the current iteration
of the run loop.  If I want to build up a path by appending a bunch of
strings, I don't need to retain any of the intermediate strings I get
along the way:  they're autoreleased, and if I don't want them to
persist, I can just let them go away when the autorelease pool is released.

> This whole idea of autorelease pools seems a little strange to me and seems
> as error prone as performing my own explicit memory management.

In practice, the use of autorelease by the framework means that much of
the time you won't need to bother with releasing temporary objects at all.

-jcr