From: pasa@lib.hu   
      
   On 12/28/2012 10:34 PM, Dave Abrahams wrote:   
   >> This is the nub of the argument, but nothing posted so far backs up   
   >> the assertion.  The preceding posts all demonstrate the use of   
   >> different loggers.   
   >   
   > It seems self-evident to me, but I'll try to explain anyway.   
   >   
   > * Most singletons are designed not to allow arbitrary lifetime   
   >    management at all, so you can only have one during the life of the   
   >    executable   
      
   Not really. One important part of this thread was exactly on this.   
   Singleton is a *design* pattern, that is about summoning an object that   
   *behaves* as the same throughout the specified time-region, and every   
   client can build on that fact.   
      
   The rest is implementation detail. It may really a single instance be   
   created early and kept for long, or may use any other magic.   
      
   And importantly it is about the designated object, not its class, so the   
   usual struggle to make a "singleton class" that focuses to *prevent*   
   multiple instances creation are way off track. And are only good to   
   shadow those working on the original goal for special cases.   
      
   For the big majority of the cases the simplest way works: you have a   
   regular class that does the job, and a global function deals with the   
   summoning stuff. Separating the responsibilities as in the book -- and   
   allowing different combinations.   
      
   Also, the "specified time-region" is not direct-mapped to "life of the   
   executable". IME the latter is pretty rare case, the most usual period   
   is after-appinit-is-done through until-shutdown-initiated. (Extending   
   that needs special treatment, careful planning and documentation;   
   fortunately not needed that often.)   
   And there's no problem to set it 'from start to finish of that test   
   case' either.   
      
   > * In any case, only one instance of a singleton can exist at a given   
   >    time, by definition   
      
   Of the singleton object, sure -- but that poses no problems at all. You   
   keep thinking in the must-be-a-class terms.   
      
   But even with a class packed solution it need not be a testing problem,   
   as you can force creation at start of case and erase it at the end of   
   it. Next case will start afresh.   
      
   The only test scenario hurt is the one we already discussed, if you   
   launch the cases in multiple threads instead of sequentially.   
      
   > * Therefore if you have two tests that need to talk to different loggers   
   >    they either must be in separate executables (in the first case) or at   
   >    least can't run in separate threads (in the second case).   
   >   
   > What am I missing?   
      
   The last point is correct formally. But IME it is hardly a practical   
   problem, because:   
      
   * when the program is generally not thread-aware, MT tests tests will   
   not fit the picture   
      
   * when the program is thread-aware, and uses singletons, those will be   
   even more thread-aware. and though you can not separate the instances   
   the test will do its job fine   
      
   I agree that you can find a few test cases where you actually look into   
   the singleton's state as well, and need to use the original, but it is a   
   small minority. That can be "packaged" separately for either build or   
   just execution.   
      
   * thinking of systems I saw that had actual tests, there were many units   
   many dozens of executables even for small LOC ones. It looks impractical   
   to struggle multithreading on this level rather than on the suite level.   
      
   * as already mentioned IME singletons are normally found in Application   
   part and rare in Library parts (for a ton of trivial reasons). And   
   application testing is way tricky in its own right let alone making it   
   parallel internally.   
      
      
   So in summary, I don't mind an assertion like 'singletons, in SOME rare   
   cases can hurt a MULTITHREADED approach of testing', but extrapolating   
   that to a general test-hindering is IMNSHO just @#$@!#$!@.   
      
      
   --   
         [ 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)