From: miles@gnu.org   
      
   Zeljko Vrba  writes:   
   > 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) since the   
   > destructor is empty, but it obviously wasn't: reducing the vector size   
   > from 1024 to 17 made an orders of magnitude improvement in running   
   > time (the vector was used as a storage for open-addressing hashing   
   > scheme).  Also, some memory reallocations were going on there.   
      
   That sounds pretty suspicious -- it is O(1) in a decent implementation   
   in this case.  [Were you perhaps using a debugging mode or version of   
   the STL (which might do some sort of poisoning of deallocated regions   
   or something)?]   
      
   So I guess the lesson is: bad implementations exist.  But on the other   
   hand, bad compilers, poor OSes, etc, exist too.  One has to make some   
   minimal assumptions.   
      
   The interesting question is:  how good are _most_ / typical   
   implementations, or more precisely, how good are the implementations   
   _you care about_, on average?  This, at least, can be tested, and some   
   sort of informed judgement made.  [The mere _possibility_ of a poor   
   implementation, though, is not such a good reason to avoid something.]   
      
   15 years ago, things were less developed, the STL was not so standard,   
   compilers did a poorer job, there were lots of issues with templates,   
   exception support sucked, etc.  So back then maybe there would be some   
   excuse to avoid the STL and other features.  Nowadays I don't think   
   it's a very supportable position except in very specific situations   
   (e.g. hard embedded where every byte and cycle is super precious, and   
   having your own implementation of everything adds necessary control   
   and accountability [and you want to use specialized structures that   
   avoid common overheads anyway]).   
      
   My suspicion is that the people on this project who are resisting the   
   STL cut their teeth on C++ back in the "bad old days", and haven't had   
   enough modern C++ experience to unlearn those instincts...   
      
   -miles   
      
   --   
   `Life is a boundless sea of bitterness'   
      
      
         [ 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)