Re: Autorelease Question
Re: Autorelease Question
- Subject: Re: Autorelease Question
- From: "Michael Ash" <email@hidden>
- Date: Wed, 19 Nov 2008 23:38:05 -0500
On Wed, Nov 19, 2008 at 6:31 PM, Kyle Sluder
<email@hidden> wrote:
> On Wed, Nov 19, 2008 at 6:17 PM, Filip van der Meeren
> <email@hidden> wrote:
>> If you wait until the end of your method to autorelease the object, you are
>> leaving a whole range of possible memoryleaks open, since every call you
>> make between the allocation and release is a call that might throw an
>> exception (and we all know Objective-C uses memoryjumps from C).
>
> Gah! You have no idea when an autoreleased object is going to be
> released. What if a method call you make in between autoreleasing the
> object and really not needing it anymore hits the top of the runloop?
> Boom, your autoreleased object is gone. As the documentation states,
> only use autorelease to signal that you no longer need an object.
What if a crocodile climbs out of your toilet and devours you while
you're busily working on your next Cocoa app?
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.
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.
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.
Mike
_______________________________________________
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