From: dave@boostpro.com   
      
   on Fri Jun 08 2012, "Martin B." <0xCDCDCDCD-AT-gmx.at> wrote:   
      
   >> The implementor of the algorithm simply avoids declaring temporary   
   >> objects in his loops.  The algorithm implementor is not (or should   
   >> not be) subject to your guideline.  In fact, the guideline should   
   >> probably be rewritten in the form, "avoid doing XXX, or if you must,   
   >> encapsulate it."  That's pretty much the right form for most things   
   >> one might want to generally prohibit, like casts.   
   >   
   > Ah! Ok, I get it.   
   >   
   > Of course, iff I'm going to write an algorithm, it's gonna be as   
   > efficient as it gets without contorting myself.   
   >   
   > BUT -- that's really missing the point I think: The examples I gave in   
   > the OP were just that: examples. People are *going to* write loops   
   > that don't make much sense as algorithms (-> used once).   
      
   The fact that they're used once doesn't mean they make no sense as   
   algorithms.  In fact, I'd bet 99% of those loops could be profitably   
   rewritten to use algorithms that already exist.   
      
   > And summed up over the codebase, there will be a lot of these   
   > (different) loops. And some (few?) of these loops will mess up   
   > performance in one (minor) way or another.   
      
   If they're important enough to optimize, they're important enough to   
   encapsulate.   
      
   > And then I will have to mess around with the guidelines because some   
   > took them too literally and now think they have to micro-optimize   
   > everywhere.   
      
   What would lead people to that conclusion?   
      
   > I really asked this question because I though there might be a   
   > technical, elegant solution out of this, but since noone posted   
   > anything that I found particularly enlightening(*), I guess there   
   > really isn't a technical solution to this, but it has to be addressed   
   > on the pedagogical and psychological level :-)   
   >   
   > (*): Although I have to say I found the idea of declaring a struct in   
   > the for loop header intriguing. (If a bit weird.)  `for(struct{   
   > std::string s, int i } vals = {..., 0}; ...)`   
      
   Intriguing, but you should make sure it doesn't defeat optimization by   
   forcing some of those struct members out of registers.   
      
   --   
   Dave Abrahams   
   BoostPro Computing   
   http://www.boostpro.com   
      
      
         [ 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)