Re: Is Apple's singleton sample code correct?
Re: Is Apple's singleton sample code correct?
- Subject: Re: Is Apple's singleton sample code correct?
- From: Andrew Merenbach <email@hidden>
- Date: Tue, 29 Nov 2005 19:56:26 -0800
I'm afraid that I'm no expert here, and I'm not positive that this
would solve a great many problems, but in order to make more people
happy with what's been suggested, how about a 'shouldCleanUp'
variable (BOOL) type--set to NO in the -init method?
Every time that the overridden release is called, nothing will be
done--unless 'shouldCleanUp' has been set to YES through an accessor,
in which case dealloc will not be *explicitly* summoned, but
(assuming that the client's memory management is correct) will at
least have a fair shot of being called.
Notifications do look a good way to clean things up (although we've
all discussed the ideas of *philosophy,* too, of which I have
little ;) ), but I've not used a huge number of singletons, so I
can't offer much more.
Best,
Andrew
On Nov 29, 2005, at 5:09 PM, David Gimeno Gost wrote:
On 29 Nov 2005, at 23:58, Andreas Mayer wrote:
I'm not saying that everyone should use object deallocation to do
resource cleanup, I'm just saying that there is nothing wrong
about doing things that way,
It's wrong when you are using Cocoa because you can't be sure that
dealloc will be called at all.
Sending an additional release won't help since there might be
other objects that are still holding on to the object in question.
And this is exactly the behavior that I would expect. Either those
other objects are also released or they aren't. If they are, their -
dealloc method shall send the required -release message. If they
aren't, that would be a bug in my code, not an incompatibility with
the Cocoa model.
Note also that for this to happen to a singleton, it requires that
the object that is retaining it is ignoring the fact that it is a
singleton.
It's best to not fight the framework. To do so will make your life
miserable.
Agreed, but that's not the case.
Regards.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40ucla.edu
This email sent to email@hidden
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
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