Jorge Lodos wrote:
as a "singleton" to solve the initialization order problem (the only legitimate use of the "singleton pattern", in my opinion).
Could you please elaborate? Why do you consider this is the only legitimate use for this pattern? Thanks in advance.
A singleton is simply a glorified wrapper over several global variables and functions. There is little difference between Singleton::instance().f(); and Singleton::f(); where the second Singleton is a namespace. The global variables don't become any less "evil" when they are made members of a singleton class. When a class represents an out-of-program entity that, by its nature, has a single instance, this class can be flattened into functions. This isn't black and white, of course; today's code may treat the video card as a singleton, but tomorrow's computers may add multiple video card support. In this case I still prefer something along the lines of VideoCard & get_video_card( int id ); // noncopyable or maybe even video_card_ref get_video_card( int id ); // reference copy semantics instead of the "multisingleton" way of VideoCard::instance( id ). But "true" singletons are either crippled ordinary classes or collections of global functions (under the assumption that there are no initialization order issues, of course).