Don't Use Singleton Classes (idea)

The Singletondesign 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 oneinstance 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:

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.