From: francis.glassborow@btinternet.com   
      
   I have been following the bunch of threads that this original post   
   spawned  and felt that it was time to go back to the original to try to   
   answer some of the questions in the light of what followed.   
      
   On 21/11/2012 20:56, fmatthew5876 wrote:   
   > Whenever we talk about singletons, people always want to make a   
   > class. One often cited example is some variant of this:   
   >   
   > class CMySingleton   
   > {   
   > public:   
   >     static CMySingleton& Instance()   
   >     {   
   >       static CMySingleton singleton;   
   >       return singleton;   
   >     }   
   >   
   > // Other non-static member functions   
   > private:   
   >     CMySingleton() {}                                  // Private constructor   
   >     ~CMySingleton() {}   
   >     CMySingleton(const CMySingleton&);                 // Prevent   
   > copy-construction   
   >     CMySingleton& operator=(const CMySingleton&);      // Prevent assignment   
   > };   
      
   I am not sure that that is generally widespread (and it needs revision   
   in the light of what C++12 offers, e.g. =delete)   
   >   
   > My question is why do people get locked into thinking that the   
   > singleton must be a class?   
      
      
   Some people may do but good programmers should take a broader view and   
   not just rehash the first solution regardless as to the detail of the   
   problem being addressed.   
      
   The problem with the above is first you   
   > can't control when destruction happens, and second, getting a static   
   > object from a function is actually very expensive. Everytime you call   
   > Instance() the compiler inserts a hidden check to see if the static   
   > object was already initialized. So thats one unneeded branch everytime   
   > you fetch the singleton.   
      
   I think that is only an apparent problem. The check will be pretty quick   
   (normally just a single flag) and often will only cost the first couple   
   of times as the execution will probably be using some variant of branch   
   prediction. In the context of real code I think you would find it hard   
   to measure the cost (and the alternatives have their own costs)   
      
   >   
   > It gets much worse though. Because of thread safety, gcc actually   
   > inserts locking code into the Instance() function, meaning not only   
   > are you doing useless branching, but you also have to grab and release   
   > locks.   
      
   But that is a necessary cost for using global (mutable) data in a   
   multi-threading environment.   
   >   
   > Why not free ourselves from the "everything must be objects" mentally   
   > and just use free functions. For example:   
      
   Well I agree with that but I do not have that mentality, nor do good   
   programmers. One size fits all mentality is the hall mark of the mediocre.   
      
   >   
   > namespace singleton {   
   > void init(/*args */);   
   > void shutdown():   
   > //other singleton methods   
   > }   
   >   
   > Now I can control when the singleton gets initialized and   
   > destroyed.   
      
   Now you have to control that:)   
   In addition I can also hide the global state of the   
   > singleton in its cpp file and I get to decide whether its heap   
   > allocated or just placed in global memory.   
      
   Sometimes an advantage and sometimes not. You are just proposing a   
   different 'one size fits all' solution, though perhaps a more versatile   
   one (at a cost)   
      
   The problem with 'singleton' mentality is that the trigger to many is   
   simply that the program needs only one (or none) instance. That is only   
   part of the problem and choosing an appropriate solution requires a much   
   wider knowledge of potential solutions coupled with an understanding of   
   the whole context in which the solution will ne applied.   
      
   I think the fundamental flaw with the 'Singleton pattern' is that it   
   focuses on a single aspect of a problem and so results in far too many   
   inappropriate uses. This leads to it being reclassified as an anti-pattern.   
      
   The deep problem is the whole concept of patterns as being appropriate   
   for use by inexpert/inexperienced programmers. Books on patterns should   
   be put on the restricted list, only to be read by those who have at   
   least reached journeyman status in programming. Of course publishers   
   would not like that because the sales would be minuscule :)   
      
   Francis   
      
      
   --   
         [ 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)