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: Dietmar Planitzer <email@hidden>
- Date: Sun, 4 Dec 2005 00:11:28 +0100
On Dec 3, 2005, at 1:19 AM, Shaun Wexler wrote:
On Dec 2, 2005, at 3:24 PM, Dietmar Planitzer wrote:
What is the sound and important technical reason for overriding
the reference counting methods in the case of a singleton ?
To prevent it's accidental deallocation, when no other objects
happen to be retaining it. Secondary reason would be that ref-
counting methods are expensive, and for example in the case of
NSNull, being repeatedly retained when inserted and released when
removed from collections is highly-unnecessary overhead; by
overriding ref-count methods, that overhead reduces to a method
dispatch. Foundation and certain AppKit objects maintain a local
refcount ivar for efficiency. Objects normally have an implied
refCount of 1, and additional references are recorded in a maptable
(ie dictionary) keyed by the object's id; it's not cheap.
Ad accidental deallocation:
This is a general problem which applies to all kinds of objects, be
they singletons or non-singeltons, be they local or remote, be they
small, large or huge, that is caused by buggy code in the
application, the implementation of the singleton, or both. There is
no reason why this general problem should be "fixed" only for a
subset of all objects that are possibly passing through the faulty
code path in the application. Overriding the reference counting
methods in the singleton class does nothing to fix the actual
problem. It does not remove the bug in the application and in fact it
makes it harder to find that bug and to remove it. The faulty code
may no longer be an immediate problem as long as we ever only pass a
reference to the singleton to it, but if we pass a regular object to
it, then the application can still crash.
The correct solution is to find the bug and to fix it. Overriding the
reference counting methods of the singleton class so that they do
nothing is not a solution, does not help to make the application more
stable and only serves to create a false perception of application
stability and correctness.
Ad reference counting overhead:
The reference counting overhead is a general problem and is not
specific to singletons. So, just like above, it should be solved in a
general way so that ideally all objects which exist in the
application can profit from the performance improvement. However, the
main question is whether overriding the reference counting methods of
a singleton so that they do nothing has even any noticeable impact on
the execution time of a typical application. I personally highly
doubt it and think that it's much better to spend time on profiling
the application in order to find the real causers of the performance
problems than to spend time on overriding methods so that they do
nothing.
And just to make it clear: I'm not going to accept answers like,
it makes ref counting faster or it makes it possible to violate
the CMM rules in the implementation of the singleton's +alloc and -
copy methods, or that is how NeXT did it. I'm sorry, but those are
not sound technical reasons for me.
I guess you need to tell us the answer then, because you're
apparently disinclined to accept the answers so given.
The answer is simple:
There is no sound technical reason for overriding the reference
counting methods of a singleton class. The only difference between a
singleton and a non-singleton class is that the former can only have
at most one instance at a given point in time. Otherwise there is no
difference to a non-singleton class. Since, except for the number of
instances, a singleton is technically just like any other object, it
does not make sense to treat singletons any differently with regard
to the Cocoa memory management rules.
Regards,
Dietmar Planitzer
_______________________________________________
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