From: pasa@lib.hu   
      
   On 12/14/2012 1:21 AM, Öö Tiib wrote:   
      
   > 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?   
      
   I used two from that list. In MFC-based projects you start with theApp   
   that is instance of something derived from CApplication. I normally   
   tried to access all other app-tied singletons from here (settings, user   
   preferences, command line, etc).   Then I used the same practice for   
   other apps. Still fail to see any problem with it.   
      
   The other one is Database -- In a period I wrote many programs that   
   started with creating one ODBC connection with a database, and the job   
   was to read/write data in that. Again see no problem -- even for cases   
   where secondary connections were opened for some technical reasons.   
      
   > 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++.   
      
   IMO the Singleton patterns imply mutable state. Otherwise we face the   
   Monostate pattern, and it's counterproductive to mess them.  (monostate   
   covers both the stateless and immutable stuff).   
      
      
   > 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.   
      
   I agree with all that.   
      
      
   --   
         [ 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)