On Fri, Mar 13, 2009 at 2:03 PM, Paul Sanders <p.sand...@dsl.pipex.com> wrote: >> Without any sort of management, you'd leak memory like >> crazy in situations where neither the caller or the callee can release >> the object. > > A scheme where it is always the caller's job to release any object returned > to it is perfectly viable, as any number of other computing platforms (such > as COM on Windows) will testify. The callee simply has to retain the object > before it returns it (and autorelease pools would not exist - hooray!). > Cocoa is one of a kind in this regard, as far as I know.
No need to look to Windows, OS X's own CoreFoundation has this kind of memory management: manual refcounting, no autorelease. It does indeed work. It's also tremendously verbose. What would be a simple one-liner in Cocoa turns into a sprawling mess of code due to the need to release temporary objects. Worse, it forces the API to expose implementation details. When there's a Get function (one which returns an object you don't own) in CF-land, that means that whatever you're calling necessarily retains a reference to it. If Apple later on wants to change how it works internally so that the function returns a temporary object instead, well, too bad, can't! In Cocoa, the existence of autorelease allows the interface's ownership semantics to be fully separated from the implementation. I'll agree that no-autorelease refcounting is viable, as is proven by many implementations, but I'll also argue that autorelease adds significant capabilities to the system. Mike _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
