Singleton considered harmful
If you've worked on an object-oriented system you've probably encountered singleton classes, classes which can have only one instance. Sometimes also known as "Highlander classes", as in "there can be only one".
Singletons are the gotos of data and should be avoided just like goto. The "convenience" of the standard singleton pattern, that you can acess them from anywhere within your code, breaks locality just like goto does. Worse actually, since goto usually can jump only within a function.

One particularly insidious way to create a kind of singleton is available in C++: the static variable declared in a function. This kind of variable will be initialized only the first time the function is called and all instances of the class will share the same variable instance. This is nasty because it's hidden: there is no hint in the class declaration what's going on and even a casual inspection of the implementation may not reveal that subtle static.

So how should you avoid unnecessary singletons? The problem you're trying to solve with a singleton is often to make some kind of global state accessible. Pass around references to the state object instead, preferrably as an argument in the constructor. This also has the benefit of making it possible to supply an object of another class, conforming to the same interface; e.g. when you want to isolate a part of the system for testing you can pass a stub object (always returning the same answers) instead of the real live object which accesses a database or the internet or whatever.
Avoiding singletons is just one aspect of avoiding to be concrete. Using interfaces and factories rather than concrete classes and instances makes your system flexible and testable; which in the end translates to profitable.