The Singleton design pattern is an area of C++ philosophy where I happen to be in complete disagreement with the rest of the C++ world.  Singleton classes, as described in Gamma Et Al. are unnecessary; they add excess verbiage to code, and they are a symptom of bad design.

My challenge to you, the reader: describe for me a class that must be implemented using the form of the Singleton Pattern in Gamma Et Al..  Alternatively, describe one that is simpler, or works more efficiently, using that pattern. Put writeups to answer the challenge in Singleton Classes are necessary, you idiot cheese!

Singleton classes are unnecessary.

Let us start by examining the reason for creating a singleton:  Someone has created a class, and decided that in order for it to behave properly, there can be only one instance of that class.

As far as I can tell, they have decided incorrectly. I am going to go out on a limb and say that any class whose correct behavior appears to be dependent on exactly one instance can (and should!) be split into two classes:
 

  • A server class, which can have any number of instances.
  • A client class, which can also have any number of instances, but whose correct behavior requires having a single instance of the server class accessible to all instances of the client class.
Thus:
class Singleton
{
 private:
 Singleton();
 Singleton (Singleton const &);
 void operator= (Singleton const &);
 ~Singleton();
  void *operator new (std::size_t);
 void operator delete(void *);

 public:
 Singleton &instance() { static Singleton Instance; return Instance; }

 some_type singular_behavior();
};

becomes:

class Client
{
 private:

 class Server
 {
  public:
  some_type behavior ();
 };

 static Server &MyController() { static Server Instance; return Instance; }

 public:
 some_type singular_behavior () { MyController::behavior(); }
};

There are variations on this which take thread safety, or the order dependency of more complicated systems into account, but the above code shows the basic transformation.  In addition, although I've made the declaration of Server local to the Client, it doesn't have to be that way.  Neither does Client::MyController() have to be private to Client.
 

Singletons add excess verbiage to code.

This may seem a bit counterintuitive in light of the declarations above.   But remember:  How do you use the thing in real code?  To invoke the class's singular behavior using the Singleton pattern, you have to call Singleton::instance()::singular_behavior().

In the "split" version, you invoke Client.singular_behavior().  All those extra calls to instance(), everywhere you're looking for singular_behavior(), will get in the way of someone else understanding your code.
 

Singletons are a symptom of bad design.

How do you decide whether or not to take a bunch of functions and variables and turn them into a class?   The time-honored way, described by Bjarne Stroustrup himself, is to ask yourself: might there be two? The fact that you're thinking there must be only one of your class should be a warning.  Think about it the other way:  No matter how weird you might think your Server class is, it might happen during the lifetime of your code that you need another one.

What bad design, you might ask?  The point is, you're mixing metaphors. Some of the behavior of your class depends on a single instance of something, and the rest does not.  These two sets of behaviors should be implemented as two classes rather than one.

Suggested further reading: Arthur J. Riel, Object-Oriented Design Heuristics, 1996, Addison-Wesley, ISBN 0-201-63385-X.