From: 0xCDCDCDCD@gmx.at   
      
   On 09.06.2012 03:25, Dave Abrahams wrote:   
   > 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.   
      
   I guess that discussion is on another exhausting front.   
      
   *I* don't neccessarily disagree, but there seem to many people that do   
   disagree -- then again, those are probably the same people that find   
   algorithms weird and useless in general, and all I can say is that   
   it's hard and exhausting work to try to pr/t/each modern C++ to a team   
   not used to it.   
      
   >> 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.   
      
   Good point.   
      
   >> 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?   
      
   People already came to this conclusion, telling me we should extend   
   the guidelines so that devs are required to pre-declare complex   
   objects to avoid any inefficiencies in loops. Telling devs to do it   
   *always* certainly smells of premature optimization. That's why I   
   sought a elegant technical solution that "always" works. No silver   
   bullet I guess.   
      
   >> 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.   
      
   Hmmm ... in the general case I'm not very concerned about registers   
   vs.  no-registers, but "needless" heap de/allocations always make me   
   wary.   
      
   cheers,   
   Martin   
      
   --   
   Good C++ code is better than good C code, but   
   bad C++ can be much, much worse than bad C code.   
      
      
         [ 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)