🚀 go-pugleaf

aishdas@haven.ios.com (Micha Berger)

 > Steve Clamage (clamage@Eng.Sun.COM), the  Chair of X3J16, C++ Committee
 > writes::
 > : The C++ Committee has been unanimous (or nearly so) in its acceptance
 > : of STL. I do not believe there is any chance it will be dropped.

I agree. The STL is here to stay, and I for one am is glad that it is.

 > I don't like STL because it represents an abandonment of one of C++'s
 > strengths, the tools for implementing an object oriented design.

Preferring one tool for another for a particular task is not abandonment
of other tools in a toolset. It is the proper way to use a tool set.

An analogy: I'm not abandoning my fork because I prefer to use a spoon to
eat my soup. You can design a contraption that can be used as a spoon, a
fork, and a knife. That way, you can have a single tool rather than a
tool set. However, that ``sporkn'' is not quite as good a fork as a fork,
not quite as good a spoon as a spoon, ...

 > STL just isn't OO. It's the creation of algorythms that are not connected
 > to the data they act upon. That doesn't make STL inherently wrong, but it
 > does seem out of place in light of the number of design decisions made
 > to enable OO.

In my opinion, templates is a better mechanism for creating efficient
type-safe containers than derivation. You can build a conventional OO
container and its associated operations on top of the STL without loss
of efficiency or generality. The opposite is not the case for any
inheritance-based library I have seen. For that reason alone, the STL
is a better choice as a *standard* library.

In general, please remember that OOP is not the only effective form
of programming. Use of inheritance often leads to the most extensible,
efficient, and general systems, but not always. Associating operations
directly with a class as members often gives the greatest notational
convenience, efficiency, and maintianability, but not always.

STL is an example of a library where generality, elegance, and efficiency
were best achieved through other means. Had the containers been provided
without algorithms, programmers would have had to write their own (imagine
C-style strings without strlen(), stdcpy(), ...). Had the algorithms not
been generic, they would have had to be replicated (undoubtedly with many
minor an annoying variations), or we would have had to invent a set of
container convertion mechanisms. Had the algorithms been less general
in their interfaces, they would not have met the needs of experts.

Where needed, we regain the classical OO benefits by using objects and
pointers to polymorphic objects as elements of containers, and by using
the containers and algorithms in the implementation of more traditional
hierarchies.

C++ is a multi-paradigm language (see D&E); the aim is to utilize the
various styles where appropriate.

	- Bjarne


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