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:28:42 -0800
On Nov 19, 2004, at 7:29 PM, Ricky Sharp wrote:
On Nov 19, 2004, at 5: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.
Is there any API in TSHashTables that you can call before static
de-initialize time to release all the objects? If so, just call that
from say your delegate's applicationWillTerminate: method.
You know, I could, but TSHashTable is cross-platform code, and the PC
guys would throw a fit if I started adding in stuff like this.
In the end I'm happy with creating an autorelease pool around the
[myImage release]. It's really not that big a deal. I just wanted to
know if it was my bug or not. I'm still not 100% sure, to be honest--I
definitely get the impression that Apple WANTS me to do things a
different way, since the system was designed around using the
Objective-C messages for detecting application termination and not the
C++ way. But nobody's come out and said "this is your bug" or "this is
a Cocoa limitation that we may or may not fix," etc. Since Apple is
trying to show that Objective-C++ is a good solution for developers
with cross-platform code, maybe they should make the atexit time more
Objective-C savvy, but it's not a huge deal either way.
_______________________________________________
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