Re: Autorelease Question
Re: Autorelease Question
- Subject: Re: Autorelease Question
- From: "Kyle Sluder" <email@hidden>
- Date: Wed, 19 Nov 2008 23:48:25 -0500
On Wed, Nov 19, 2008 at 11:38 PM, Michael Ash <email@hidden> wrote:
> Seriously, this kind of hysteria does nobody any good. Nothing you do
> besides explicitly releasing/draining an NSAutoreleasePool instance
> that you explicitly created is going to drain the current autorelease
> pool. You cannot make a call that "hits the top of the runloop", as a
> call is going deeper into the stack by definition, and the top of the
> runloop is shallower in the stack. If they run a nested runloop then
> fine, those things nest.
There's a reason that the documentation says "normally guaranteed,"
not just "guaranteed":
"A received object is normally guaranteed to remain valid within the
method it was received in (exceptions include multithreaded
applications and some Distributed Objects situations, although you
must also take care if you modify the object from which you received
the object)."
http://developer.apple.com/documentation/Cocoa/Conceptual/MemoryMgmt/Tasks/MemoryManagementRules.html
> Autorelease is *not* a signal that you no longer need an object.
> That's what release does. Autorelease is a way to relinquish ownership
> of an object *without destroying it right away*. The entire reason it
> exists is so that you can safely and easily return objects to callers.
> It would be utterly useless as a construct if such objects could
> disappear at any moment.
We're saying the same things here, I think. The only issue I have is
that in between returning an object and the caller being invoked --
barring multithreading -- nothing else can happen, so your "reason" is
incorrect. Even if objects could disappear after any method call at
all, that doesn't mean that they could disappear during the return.
> The lifetime of autorelease pools is well defined and highly
> predictable. It is flat-out impossible for a Cocoa app which is not
> experiencing some sort of memory smasher or other faulty behavior to
> destroy an autoreleased object in the same scope in which it was
> autoreleased, unless there is a very obvious call to destroy an
> NSAutoreleasePool sitting right there in that code. Please, stop
> spreading misinformation.
Again, I defer to the documentation. Perhaps it's because I'm working
a lot with Distributed Objects that I'm being paranoid about object
lifetimes.
--Kyle Sluder
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden