Re: NSApplication delegate not released on quit?
Re: NSApplication delegate not released on quit?
- Subject: Re: NSApplication delegate not released on quit?
- From: publiclook <email@hidden>
- Date: Sat, 14 Jun 2003 09:40:40 -0400
NSApp does not retain its delegate so it should not release it.
Top level objects loaded from a nib file have a retain count of 1.
Classes like NSWindowController take care of releasing the top level
object in nibs that the window controller loaded.
The main menu nib is loaded automatically early in application startup,
and it is probably possible for the code that loads the main menu nib
to release its top level objects at application shutdown, but what
would be the point. As many people have observed, the top level
objects in main menu nib need to exist right up to the last moment of
the applications existence and then they might as well all be cleaned
up at once.
On Friday, June 13, 2003, at 11:22 PM, Greg Hurrell wrote:
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.
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...
Just my opinion.
Cheers
Greg
_______________________________________________
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.
_______________________________________________
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.