Re: NSApplication delegate not released on quit?
Re: NSApplication delegate not released on quit?
- Subject: Re: NSApplication delegate not released on quit?
- From: Marco Scheurer <email@hidden>
- Date: Sat, 14 Jun 2003 06:05:23 +0200
El sabado, 14 juni, 2003, a las 07:22 Australia/Adelaide, Sherm
Pendley escribis:
There's no real point to releasing the delegate at all in this
situation. All it will do is release the memory used by that object
back to the application's memory heap - but that entire heap will be
released back to the OS when your app exits anyway. All you'd really
accomplish with an autorelease at that point would be a slight
increase in the amount of time it takes your app to shut down.
I for one am sick of hearing this reply in response to questions about
clean-up at app shutdown time.
The slowdown argument is invalid due to the tiny timescales involved.
The "it doesn't do any harm" argument might be fine in practice, but
from a programming principles perspective it violates all the codes
about design by contract.
As programmers, we are taught basic rules like:
- balance each malloc() with a free();
- send a release for every alloc/copy etc;
Basically it all boils down to symmetry, and cleaning up after
yourself. You should be able to expect that all objects/classes etc
abiding by the contract behave in the agreed upon manner.
So all your singleton objects should register themselves to the
NSApplicationWillTerminateNotification to free themselves? Or a message
should be sent to classes to do it? I'm pretty sure there are more
interesting and useful things to do in your code than that. I don't see
why admitting that some "immortal" objects live until the application
dies is such a big deal. Think of it as another kind of contract, and
you're done.
Here, clearly, AppKit (or something else) is at fault. In this case it
looks like NSApp is retaining its delegate and never releasing it, so
it's breaking the code.
A programmer who makes the quite reasonable assumption that NSApp will
release at dealloc time the things it previously retained, will be
bitten by this bug.
It might be a "harmless" bug in most cases. But how can it be argued
that this is a good thing? What if the code is ever ported to a
platform where the (correct) behaviour is maintained? Or to a platform
where the OS doesn't do the cleanup of leaked resources?
I wish the behaviour wasn't like this. And if it were corrected, and a
programmer still cared so much about application shutdown time that
he/she wanted to skip the proper deallocation phase, he/she could
always just override the dealloc method and make it do nothing...
More than optimizing shutdown time, the reason not to care about it is
that it saves you programming and thinking time, and makes your design
simpler. This is not a case of premature optimization.
Marco Scheurer
Sen:te, Lausanne, Switzerland
http://www.sente.ch
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.