Re: Singletons
I have been following the bunch of threads that this original post
spawned and felt that it was time to go back to the original to try to
answer some of the questions in the light of what followed.
On 21/11/2012 20:56, fmatthew5876 wrote:
Whenever we talk about singletons, people always want to make a
class. One often cited example is some variant of this:
class CMySingleton
{
public:
static CMySingleton& Instance()
{
static CMySingleton singleton;
return singleton;
}
// Other non-static member functions
private:
CMySingleton() {} // Private constructor
~CMySingleton() {}
CMySingleton(const CMySingleton&); // Prevent
copy-construction
CMySingleton& operator=(const CMySingleton&); // Prevent assignment
};
I am not sure that that is generally widespread (and it needs revision
in the light of what C++12 offers, e.g. =delete)
My question is why do people get locked into thinking that the
singleton must be a class?
Some people may do but good programmers should take a broader view and
not just rehash the first solution regardless as to the detail of the
problem being addressed.
The problem with the above is first you
can't control when destruction happens, and second, getting a static
object from a function is actually very expensive. Everytime you call
Instance() the compiler inserts a hidden check to see if the static
object was already initialized. So thats one unneeded branch everytime
you fetch the singleton.
I think that is only an apparent problem. The check will be pretty quick
(normally just a single flag) and often will only cost the first couple
of times as the execution will probably be using some variant of branch
prediction. In the context of real code I think you would find it hard
to measure the cost (and the alternatives have their own costs)
It gets much worse though. Because of thread safety, gcc actually
inserts locking code into the Instance() function, meaning not only
are you doing useless branching, but you also have to grab and release
locks.
But that is a necessary cost for using global (mutable) data in a
multi-threading environment.
Why not free ourselves from the "everything must be objects" mentally
and just use free functions. For example:
Well I agree with that but I do not have that mentality, nor do good
programmers. One size fits all mentality is the hall mark of the mediocre.
namespace singleton {
void init(/*args */);
void shutdown():
//other singleton methods
}
Now I can control when the singleton gets initialized and
destroyed.
Now you have to control that:)
In addition I can also hide the global state of the
singleton in its cpp file and I get to decide whether its heap
allocated or just placed in global memory.
Sometimes an advantage and sometimes not. You are just proposing a
different 'one size fits all' solution, though perhaps a more versatile
one (at a cost)
The problem with 'singleton' mentality is that the trigger to many is
simply that the program needs only one (or none) instance. That is only
part of the problem and choosing an appropriate solution requires a much
wider knowledge of potential solutions coupled with an understanding of
the whole context in which the solution will ne applied.
I think the fundamental flaw with the 'Singleton pattern' is that it
focuses on a single aspect of a problem and so results in far too many
inappropriate uses. This leads to it being reclassified as an anti-pattern.
The deep problem is the whole concept of patterns as being appropriate
for use by inexpert/inexperienced programmers. Books on patterns should
be put on the restricted list, only to be read by those who have at
least reached journeyman status in programming. Of course publishers
would not like that because the sales would be minuscule :)
Francis
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]