From: ootiib@hot.ee   
      
   On Wednesday, 12 December 2012 08:47:25 UTC+2, fmatthew5876  wrote:   
   > It seems we have gotten very deep into the global variables debate. Lets   
   > try to back up a step.   
      
   Without concrete examples it is hard to discuss. There are things that   
   are nonsense to generalize out of context. Singular state is one of   
   such things.   
      
   > My original question was about using singletons to represent global state   
   > as opposed to other methods such as free functions within a namespace.   
   >   
   > Assuming globals aren't evil and you have a legitimate reason to use them   
   > for something, what method or pattern do you like to use?   
      
   First ... about your idea in general. Making unit tests is difficult   
   when singular state on what your unit depends is behind free functions   
   and you use some mocking framework that does not help turning free   
   functions into mock versions.   
      
   What is your original "CMySingleton"/singleton? The unmaintainable   
   classes that I have seen were always the classes of singular objects   
   with "godly" names ... Application, FolderTree, Document, Form1, View,   
   DataBase, MainFrame and Manager. One of those?   
      
   If there happens to be one and only one object of a kind in particular   
   application but it is easy to imagine it to be not single in some   
   other application then designing special singleton class for it is bad   
   idea. Wrapping it into free functions is also bad idea as is making it   
   global for access to everybody. So there is a single "view". Why to   
   carve such exceptional situation into rock? Just pass its reference to   
   these who need access to a view. Can not be too hard.   
      
   Injected dependency does not have to be pointer or reference in C++.   
   For example ... allocator. It may have (shared between all allocators   
   of same type) singular common allocation pool. So injection goes with   
   type of allocator. Access to (and even indication of existence of) the   
   pool is abstracted totally away behind (non-singular) allocator   
   objects.   
      
   Free function fits best for (at least observably) immutable global   
   state. With inlines and constexpr most overhead and inconvenience is   
   reduced.   
      
   Some languages demand a "doer" for every function even if there are   
   none. That can be called "nonexistent global state". No such   
   (stateless singletons) needed in C++. Two silly examples to illustrate   
   what I mean:   
      
     threadId = std::this_thread::get_id();   
     threadId = ThreadingGenie::getInstance()->tellMeCurrentTheadId();   
      
     std::sort(names.begin(), names.end());   
     AlgorithmGenie::getInstance()->sort(names.begin(), names.end());   
      
   Some languages do not have namespaces. Well ... C++ has. So if the   
   singleton is actually whole module or package then use namespace.   
      
   When having global state is still needed for some reason, especially   
   when the reason was "convenience", then I am in difficulty to see real   
   benefit of the global object accessed with static accessor function   
   getInstance() versus simply accessing it directly by its name (like   
   std::cout). The former feels both global state (bad) plus code bloat   
   (not that convenient) to me.   
      
   There it was ... YMMV.   
      
      
   --   
         [ 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)