From: ootiib@hot.ee   
      
   On Monday, 5 May 2014 02:01:50 UTC+3, wmac...@googlemail.com  wrote:   
   > { Double-spacing and the clc++m banner removed from the quoting.   
   >   Text reformatted to fit within 80 columns. -mod }   
   > On Thursday, June 13, 2013 7:50:42 AM UTC-6, �� Tiib wrote:   
   > > On Wednesday, 12 June 2013 15:50:59 UTC+3, Frank Bergemann  wrote:   
   > > > Here's the final version - pls. see below. But it's just an example.   
   > > > Maybe for other algorithms it will be more usable.   
   > >   
   > > IMO current model of requesting all information a function needs from   
   > > caller by declaring explicit function parameters is cleaner and simpler   
   > > to understand.   
   > >   
   > > That Dobbs article seemingly misses the point. Exceptions are necessary   
   > > evil ... efficient way to deal with very rare concerns. Now if a function   
   > > realizes that it can not do what it should because some access is not   
   > > granted or keys are not authorized then it should either abort the   
   > > program or throw exceptions or return error (depends on its contract   
   > > requirements). Somehow hacking and repairing the situation by doing   
   > > something that is far above its responsibilities is most evil thing to do   
   > > because it results with spaghetti code that we all hate.   
   >   
   > I am the author.  I agree that, like the exception mechanism,   
   > retain/recall should only occasionally be used.  Named parameters or   
   > instance data are typically better choices for getting information to   
   > a method that needs it.   
      
   Yes, maybe my posts put the idea forward too strongly.   
      
   >  The point of the article was to define a grey   
   > area between these choices, and global variables (essentially the only   
   > other choice without retain/recall).  The example applications in the   
   > code illustrate a group of problems where retain/recall significantly   
   > simplifies solving certain reasonably common problems.   
      
   I try to review them choices, then.   
      
   * 1 Translation/i18n. User's language is usually application-wide choice.   
   When there is deviation (User speaks Finnish but needs a document   
   exported/printed in Danish) then the "current language" can be temporarily   
   (for preparing the document) switched to Danish and Finnish is restored   
   afterwards with RAII. when there are multiple threads that deal with readable   
   texts then the "current language" can be designed (or refactored) into   
   thread-local choice for same effect. Technically your suggestion does   
   same thing, but that feels less transparent.   
      
   * 2 Logging. Most prefer it as very robust, fast, global service. One   
   direction, output only. Further processing/splitting of logs for its   
   consumers (per thread or otherwise) is simpler to not make responsibility   
   of logging. When it is needed then it is cheaper to log thread id in log   
   records. The distinction/filtering/splitting can then be made as   
   responsibility of processes that use log as their input; logging application   
   may have more important things to do.   
      
   * 3 Footnotes. I did not understand the idea, sorry.   
      
   * 4 Building. and 7 Checkpoints. I felt these are two views to same problem.   
   "Checkpoints" were in article described as specific spots in "Building" some   
   object/structure? Actually there may be merit when building complex   
   things may fail (but unsure how deeply completely) or succeed (but   
   unsure how optimally). General trend is to go (possibly massively) parallel   
   when attacking such complex problems ... however taking advantage   
   of stack of thread somehow may be also useful on some case.   
      
   * 5 Pooling. Thread-local pool makes certainly sense but it might be   
   easier to understand it as a "thread-local pool". IOW I do not see   
   the benefit of call stack with it.   
      
   * 6 Reusing. Yes, sometimes some legacy library has to solve   
   problems that it is not designed to solve. It may be hacked to do   
   that in various ways. There may be situation when your retain/recall   
   is among least evil.   
      
      
   --   
         [ 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)