If an object is actually required, but there should be only one instance that is universally accessed, use a singleton object. There are many situations in C++ where an object is actually required - to minimise coupling with a (run-time) polymorphic interface, to facilitate certain overloaded operators (for instance, to implement a function object), to implement a simple standard library compatible pool allocator ...
If an object is not actually required, strongly favour a namespace over a class with (only) static members.
In particular, blithely ignore stentorian exhortations like:
'do not use singletons (in the parlance popular amongst the denizens of the lounge, "singletons are evil")
or 'do not use variables at namespace scope ("global variables are evil")'.
The singleton (like the facade) is a 'pure' pattern - a reusable design idea without a canned 'reference implementation'. Unfortunately, almost all the discussions on the web treat the example from gang of four as the 'reference implementation' (or worse, as the one and only possible implementation) of a singleton.
The singleton design pattern is unique in that ... it's description is simple, but it's implementation is complicated
- Alexandrescu in 'Modern C++ Design'.
In the next 25 pages or so, he goes on to discuss singleton implementation choices.
Boost has been struggling for years now, with the idea of a generic, reusable singleton implementation.
Out of curiosity, I searched the boost include directory for headers with 'singleton' in the name, and got:
Interestingly, only pool, serialization and test exposed the singleton in the library interface.
Which too seems to be characteristic of singletons in real-life code; used more often to support the implementation than to present an interface.
When you decide, if you need Singleton, ask two sets of questions: Do I need global access point to instnce of class? Why? Do I need to restrict creation of additional instances? Why?
If you need it and can tell why, use Singleton.