Re: My bug or Apple's?
Re: My bug or Apple's?
- Subject: Re: My bug or Apple's?
- From: John Stiles <email@hidden>
- Date: Fri, 19 Nov 2004 22:32:13 -0800
On Nov 19, 2004, at 3:18 PM, John C. Randolph wrote:
On Nov 19, 2004, at 3:04 PM, John Stiles wrote:
Well, as a matter of course, I try to release everything I allocate.
At my work, our allocator code will complain about a memory leak if I
don't.
In this particular case, TSHashTables destroy each of their elements
when they are destroyed, because that's how they were designed.
Usually it's helpful. :)
If I just wanted to leak the images, I could make my Image class'
destructor do nothing, but that seems like an error to me. Yes, in
this particular instance we're quitting anyway, so we don't HAVE to
free. But should I really need to make two separate types of Image
objects--one that frees itself on destruction, and one that
doesn't--just because of this bug? It doesn't seem logical to me.
Well, freeing individual objects when quitting an app serves no
purpose, and just makes your app take longer to exit.
My app doesn't take a long time to exit--it's basically
instantaneous--and our policy at my job is to clean up all your
allocations. (a) It's not my place to challenge that policy, and (b) I
think it enforces good programming practices. If we were taking a long
time to shut down, then I'd look at ways to speed it up, probably by
putting all my allocations into a pool or zone or something.
The problem you're hitting here is that you're using Cocoa objects
after the framework has finished its
normal shutdown procedure: that's why there's no autorelease pool in
place.
I'd say your best bet is to set a global "isTerminating" flag when the
user quits, and have your destructors check that flag and do nothing
if it's set.
Is there anything wrong with just making an autorelease pool around the
[myImage release]? That's a less invasive solution and seems to have
solved the problem I was having.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden