From: ootiib@hot.ee   
      
   On Friday, 14 June 2013 16:20:02 UTC+3, Bart van Ingen Schenau  wrote:   
   > On Thu, 13 Jun 2013 06:50:42 -0700, Öö 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.   
   >   
   > I don't agree with that, but I do feel that the OP misses the point of   
   > the Dr.Dobbs article.   
      
   Maybe so. One is certain that I fit to the pack of people being confused   
   here.   
      
   > I agree that usually passing information through explicit function   
   > parameters is best, but there can be some rare cases where other methods   
   > are better. In those situations, people currently reach for global   
   > variables or singletons, but the technique described in the Dr.Dobbs   
   > article could be a reasonable alternative for those.   
      
   OK, I currently also sometimes reach for 'thread_local' in some situations.   
   With   
   poor C++11 support I have to reach for '__thread' or '__declspec(thread)' or   
      
   'boost::thread_specific_ptr<>' but that is hopefully temporary. Author of   
   article   
   failed to mention that. Instead he named it as retain recall and   
   anchestor stack blah blah. It was sly of him. No wonder I was confused. It   
   is   
   irrelevant if thread local object points at some objects in stack or lives   
   its own   
   life at side of stack. With RAII stack can be always kept synchronized with   
   other   
   thread local things.   
      
   > > 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.   
   >   
   > The Dobbs article describes a way to pass information from a caller to a   
   > distant possible callee, without bothering the intervening function with   
   > all the possible information needs for all the possible callees.   
      
   That I got. Oh I think I got everything now.   
      
   > The link with exceptions is not that it in some way could repair errors,   
   > but that both mechanisms deal with long-range communications without   
   > making the intervening functions aware of the details.   
      
   I will still use thread local objects openly no point to hide it as   
   "retain-recall-semantics".   
      
      
   --   
         [ 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)