🚀 go-pugleaf

(My previous similar article got lost somehow. Since then the original
 post has expired at this site.)

James Kanze essentially asked earlier in this thread: 
``Why would anyone _not_ want the STL to be part of standard C++?''

One argument that I've heard (and with which I sympathize to a certain
degree) is that the standard C++ library should consist only of those
elements that are hard or innefficient to implement portably using the 
core language.

For example, the implementation of the I/O part of the library is highly 
dependent on the underlying platform (hardware+OS), while a char-string
library is likely to benefit from hardware support on several common
architectures.

Most of the STL on the other hand can be efficiently implemented using
the core language features and traditional optimizing methods.

IMO, the major advantage of having standardized what is now called STL,
is that it has shown to:
    1) the public how to better use C++ to obtain efficient, yet 
       loosely coupled (and hence more reusable) software components,
and 2) the C++ designers which additional template features would be 
       helpful to support such designs.

However, being part of the standard, STL may very well cause progress 
to stiffle in the techniques used to implement fundamental data 
structures and algorithms. Indeed one may fear that if someone came up 
with a design that is significantly ``superior'' to STL, chances are that
her ideas would be turned down because ``they are not standard''.

OTOH, the idea that ``a standard library decomposition method'' is an
essential benefit of STL being part of standard C++ seems weakened by
the fact that some vendors have announced that they will ``hide'' STL
under their own design strategies.

	The Devil's Advocate
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]