🚀 go-pugleaf

matt@cyclops5.berkeley.edu (Matt Austern) wrote:
>
>The good news, though, is that the STL isn't a container class library
>in any conventional sense; it isn't even a container, iterator, and
>algorithm library either, although that comes closer.  What it really
>is is a set of requirements that containers, iterators, and algorithms
>must satisfy if they are to work together, and a fairly large but
>deliberately incomplete set of predefined containers, iterators, and
>algorithms.

   I agree STRONGLY with this characterisation. In fact,
I'd venture to do one step further (as I usual do :-)

   STL isn't even a set of requirements (to be met by various
components). It's a FRAMEWORK for creating such requirements,
for ANY kind of generic component. (See Stepanov's papers,
available from various WEB servers)

  TO explain: it is impossible to divorce C++ from STL,
especially the template facilities. What Stepanov, Musser and Lee
have done is provided the bootstrap, namely the notion of
sequences. The framework is implicit, but it is a DOCUMENTATION
STANDARD, not a piece of software, or even specs for such software,
or even specs for that category of software: its a specification
(by example) of how to specify generic library architectures.

  For example, how would you do a graphics library
after seeing STL? [The same way STL is done]. How about
doing a matrix library with optimisation opportunities
for parallel execution? [The same way as STL]

  None of this would have been possible in C++ without
Bjarne Stroustrup's patient and persistent efforts to
upgrade the C++ language -- despite the difficulties
presented by the standardisation effort.

>If you look in the draft standard, by the way, you'll see no mention
>of the STL in the table of contents.  It's a very important part of
>the standard C++ class library, .....

  .. according to my interpretation the WHOLE Working Paper is
nothing but a particular component of the STL standard,
so you have it backwards -- ISO Standard C++ is (will be)
part of STL, not the other way around :-)

  STL makes a number of things clear not present in other C++ libraries:

* the way to handle errors (DONT, document what leads to them),

* the way to make things efficient (DON'T, document complexity requirements),

* the way to make the system meet the widest needs:
   (DONT, make it extensible, flexible, generic and reusable,
   DECOUPLE the components, and document the requirements for coupling
   them together), 

* the way to make things comprehensible
  (DON'T, define the notions rigorously, and make them mathematically
   simple -- leave comprehension to book writers).


In ISO C++, we have the categories Matt mentions: iterators,
containers (which are used to source the iterators), and
algorithms (which do work on the values stored in containers
via the iterators). These three _categories_ form a fairly
minimal sequential processing model. They're NOT
enough to handle real world requirments, which include
GUI's, databases, real time interactive I/O, and other 
things. But they show the way so that these things can be
decoupled into categories, analysed mathematically,
and specifications formulated, to allow interoperable
and reusable software components covering a larger
range of requirements to be developed.

Isn't that, more than anything else, what is needed
in the software industry?

-- 
John Max Skaller               voice: 61-2-566-2189
81 Glebe Point Rd              fax:   61-2-660-0850
GLEBE NSW 2037                 email: maxtal@suphys.physics.oz.au
AUSTRALIA                      email: skaller@maxtal.com.au



[ 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. ]