From: ootiib@hot.ee   
      
   On Friday, 4 October 2013 10:00:02 UTC+3, fmatthew5876  wrote:   
   > > > * A logger   
   > >   
   > > It is too easy to imagine how you want to have several logs and so   
   > > loggers. Examples: module-specific log, thread-specific log,   
   > > "project"-specific[1] log.   
   > >   
   > > Yes, it is achievable that single logger manages them all but why?   
   >   
   > The cost of passing a logger object all over the callstack is still too   
   > high.   
      
   Call stack is one of cheapest resources but it certainly can be too   
   expensive in situations. Show me why and I fix it. Solution may be to not   
   pass it over a call stack. That still does no way mean any singletons   
   involved.   
      
   Three random ways from countless:   
   Inject logger into objects (that need logging service) in constructor of   
   objects.   
      
   Inject references to authorities. Acquire logger on need from authorities.   
   Module-specific logger from "module", user-specific logger from "user".   
      
   Work that program does is done by atomic "transactions", one "transaction"   
   is done by single thread. Start of "transaction" sets a "logger" for that   
   transaction (some thread-local variable).   
      
   > The problem is that *any* function is a good candidate for having   
   > logging which means almost every function will require a logger argument.   
   ...   
   [etc.]   
      
   I feel that you assume certain unfitting architectures (that I did not   
   even sketch) and argue against them. Do not. There are no silver bullet   
   architectures. Think of real world. If you need a spaceship then it   
   obviously has different architecture than a warehouse. Why should software   
   be different?   
      
   Also try to praise how elegantly the singletons achieve situation   
   where you /must have/ separate log for each "project" and application   
   /must deal/ with at least two "project"s at same time.   
      
   > The other examples like an event processor and database might work for   
   > some applications, but I agree they are somewhat suspect in general.   
   > I stand by the logger example though. I wouldn't do it any other way.   
      
   Before you argue with those /must/ I give two imaginary "reasons" from   
   countless: Log is elementarily needed as "Audit Trail" required by some   
   "US State Law Of Food And Beverages Production Projects". Count of   
   simultaneous parallel "project"s handled is keystone of licensing policy   
   of powerful fatsos from "Our Sales Department". It is "bread or bzzttt"   
   question if you can handle the requirements or not.   
      
      
   --   
         [ 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)