From: fmatthew5876@googlemail.com   
      
   { Reformatted; please limit your lines to 70 characters -mod }   
      
   > So you suggest that everyone who uses your singleton is supposed to   
   > call the init function? The advantage of a singleton is to hide such   
   > internal issues.   
      
   Most of the singletons I use require some runtime user supplied   
   initialization anyway. So I'd already have to be calling Instance()   
   and then some .init() function.   
      
   Also, if you have multiple singletons with dependencies, the   
   Instance() method does not save you from initializing them in the   
   wrong order. It also makes it more difficult to reason about when the   
   singleton object actually gets initialized because just about anyone   
   can call Instance() and trigger the constructor. This can be important   
   for performance and correctness.   
      
   I'd rather explicitly call init() for each singleton in main() or   
   somewhere close to it in the correct order. This works well enough in   
   an application but could be troublesome if the singletons are in a   
   deeply nested library. In that case it may be that using the   
   Instance() method is preferred. Another alternative is to allow init()   
   to silently be called multiple times.   
      
   Finally, if you don't need an init() function and don't have ordering   
   dependencies, your global data objects hidden in the cpp file can have   
   constructors that get called before main() to set things up just as   
   they would if they were global singleton objects.   
      
   > I also don't see how you can compile-time enforce the essential   
   > invariant of a singleton - namely that only one object of type X   
   > exists.   
      
   In this example there is no compile-time invariant to enforce. The   
   singleton consists of the free function API in the namespace and   
   whatever global state is squirreled away in the implementation   
   file. There's only one set of global objects in the cpp file and no   
   possible way for callers to even try to create more.   
      
   > Further, I don't see why your first variant shouldn't also allow for   
   > hiding the allocation details - there is no requirement that   
   > Instance is *defined* within the class definition.   
      
   True enough   
      
      
   --   
         [ See http://www.gotw.ca/resources/clcm.htm for info about ]   
         [ comp.lang.c++.moderated.    First time posters: Do this! ]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)