From: dave@boostpro.com   
      
   on Mon Oct 03 2011, nmm1-AT-cam.ac.uk wrote:   
      
   > In article ,   
   > Dave Abrahams   wrote:   
   >>on Sun Oct 02 2011, nmm1-AT-cam.ac.uk wrote:   
   >   
   >>   
   >>> The STL isn't very high quality, anyway, which is another problem :-(   
   >>   
   >>By what measure?   
   >>   
   >>It has its shorcomings, but along many axes, I'd say it is of very high   
   >>quality... a level of quality that easily surpasses that of any library   
   >>with similar intentions when the STL was introduced.   
   >   
   > That last may very well be true, and there are indeed several aspects   
   > where I am very impressed indeed with its design.  But remember that   
   > I have been involved in this area for 40 years.  However, let's just   
   > answer your first question.   
   >   
   > It is extremely complicated, largely because there are so many ways   
   > to do the same thing but, despite that, it is not very flexible.   
      
   That's a very general statement.  I find it quite flexible.   
      
   > Most seriously, it is not a very good basis as a starting point for   
   > more advanced containers and algorithms, as this thread has shown for   
   > multi-dimensional arrays.   
      
   I don't see how that thread showed it.  I saw some people claim it.   
   I've successfully used it as a basis for constructing multi-dimensional   
   arrays and I don't remember being frustrated by its design.  The   
   iterator concepts need to be extended (i.e. refined) in order to deal   
   effectively with sparse matrices, but concept refinement is built into   
   the design of the STL so I don't see why that should be a problem.   
      
   > It is extremely under-specified, and seriously ambiguous in a lot   
   > of important (if edge-case) aspects, even more than the C++ language.   
      
   I think you are mistaken.  There are areas where C++03's library is   
   underspecified, but they're not the areas you're pointing at.   
      
   > So far, I have found relatively few clear unimplementabilities and   
   > inconsistencies.  Let's take one example, which is pervasive but shows   
   > up particularly obviously in sorting and other rearrangements.   
   >   
   > It is unclear about exactly which constructors etc. container and   
   > other operations are allowed to use.  In particular, when may they   
   > create a temporary copy?   
      
   In exactly those circumstances where copyability is a concept   
   requirement on the element type.  This is not unclear at all to me, and   
   if you point at a specific operation I'll give you the specific answer,   
   based entirely on the standard text.   
      
   In the case of containers, in C++03, copyability is always required of a   
   container's element type, and therefore any container operation is   
   allowed to make a copy.   
      
   > That is particularly important when the location of an object is   
   > constrained or carries information (e.g.  it is commonly used as an   
   > equality breaker in sorting).   
   >   
   > But it is also important when the object includes certain types of   
   > data, such as locks and memory-mapped arrays.  How much extra   
   > complexity does the programmer have to add to defend himself against   
   > what the STL code may do?   
      
   It depends what you're worried about.  If you're worried that your   
   objects may be copied, and you're using a component that requires your   
   object to be copyable, and you're not willing to trust your vendor's QOI   
   to avoid unnecessary copies, you'd better not use the standard library   
   at all.   
      
   --   
   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)