From: 0xCDCDCDCD@gmx.at   
      
   On 12.02.2012 01:33, Zeljko Vrba wrote:   
   > On 2012-02-10, Richard Smith  wrote:   
   >>   
   >> I'm doing some coding in my spare time on an open source C++ project   
   >> which I won't name the project to avoid any embarrassment.  The code   
   >>   
   > ...   
   >   
   > PS: STL is unpredictable; I got burned on it myself.  IIRC, I had a   
   > vector of structures like this one:   
   >   
   > struct pair {   
   >    int a, b, c;   
   >    pair(int _a, int _b) : a(_a), b(_b)   
   >    { }   
   > }   
   >   
   > I frequently called vector.clear, which turned out to be a severe   
   > performance bottleneck: you would expect clear to be O(1) (...)   
   >   
   > In conclusion: if performance is critical, you cannot rely on the STL   
   > and the compiler to always do the "sane thing".   
   >   
      
   Dunno. Conclusion always seems to be, that in the end, *everything*   
   performance related is unpredictable. (To highlight: "... the STL *and   
   the compiler* ...")   
      
   Your example leaves open the question: Would it have been better if a   
   non-STL container had been used? Maybe: if it had a clear()-like   
   operation that was implemented differently. Maybe it would have been worse.   
      
   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)