In article <D6HrAD.6rt@research.att.com>,
Bjarne Stroustrup <9758-26353> 0112760 <9758-26353> wrote:

>This may urprise people who hasn't gotten used to the STL and still thinks
>in terms of libraries organized as class hierarchies, but it is not necessarily
>a bad thing. In fact, I think it is a good thing, because I have found
>class-hierarchy-based foundation libraries too constrainingand too inefficient
>for many critical uses (though of course not for anything like all uses).

 In fact, STL works hand in hand with abstract class lattices
and polymorphism. The techniques are orthogonal. The combined
power is therefore a product rather than a sum.

>One initially surprising thing is how
>concepts from other foundation libraries not directly supported by the
>STL can be fitted into the STL framework.

 I concur. My smart pointer class is great -- and it
works just fine in STL! My graphics library components work
in STL. Only problem I have is that now I want to make them
templates too :-)

 And my string class is now STL compliant. (At least I think
it is:-). The only invasive surgery required was the unfortunate
clash:

 MTLstring s(' ',65); //  used to mean 65 spaces
        //  now it means 32 'A' s.

I can live with that.

>The STL as provided by the standard is not small.

 By commercial standards it's _tiny_.  The old STL
fitted in a single header file!

 What's remarkable is that such a small library is so powerful.
>
>My experience has been that more people are overwhelmed by the sheer
>scale of what is provided than there are people who soon ask for more
>- and those who ask for more often simply ask for the familiar without
>noticing that an equivalent is already provided.

 Actually I suspect the complexity of the implementation
is a bit overwhelming: there is a lot of mechanism. At least some
of that is present to compensate for lack of suitable features in
C++ itself.

 And using it is more verbose than I find pleasing.

 In both cases a small price well worth paying.

>The part of the STL framework that is filled in for the standard is not
>random, it is a set determined by looking at real use of data structures
>and algorithms in C++ foundation libraries and foundation libraries for
>other languages.

 I agree with that. The set of containers and algorithms
chosen covers a wide territory. But it is quite small.

>I too would like to see hashed containers
>in the standard, but most of all I want to see a standard: complete,
>polished, signed and sealed! If adding hashed contained gets in the way
>of that goal, I'll do without hashed containers in the standard.
>
>I happen to think that we could have hashed containers and a standard
>without delay, but not everyone agrees and whatever the standard says
>we DO have hashed containers.

 Exactly. The same will be true for many many other
components I hope.

 You see, with any luck the next Standard will NOT be
C++ version 2.

 It will be a LIBRARY Standard. That is what industry
really needs -- standard reusable components.

>One reason, I didn't provide a standard container library - even though
>I was well aware of the need - in the early releases of C++ was that I
>didn't know how to build one that fulfilled enough of my criteria for
>a standard library. The structure of the STL surprised me too, but it
>fulfilled far more of my criteria than any other I have seen so far.

 So the original lack of a library which you have
often bemoaned .. may in fact have been a blessing in disguise.
Intuitively -- without knowing why perhaps -- you did the right thing.

 There is every chance an extant C++ container library
would have prevented the STL being adopted.

--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,
        81A Glebe Point Rd, GLEBE   Mem: SA IT/9/22,SC22/WG21
        NSW 2037, AUSTRALIA     Phone: 61-2-566-2189

In article <3lpcro$j3k@ixnews1.ix.netcom.com>,
Marian Corcoran <mcorcora@ix.netcom.com> wrote:
>
>While I,of course, would want STL to be extensible, I was surprised not
>to find more.

 There _was_ more. A whole lot was cut out. Remember,
the Standard is being prepared by volunteers. There is work
involved.

>A more extensive data structures class library, where one
>could override the existing data structures and algorithms,  would be of
>great help to programmers (especially those starting to use STL.)

 But you can override them. Two ways --

 1) on a name basis, you can use namespaces to switch
 between the Standard and any other implementation.

 2) using iterators as an intermediary, you can interface
 any algorithm to any container

>people "reinventing the wheel."  The other day on the net, someone
>expressed an interest in STL for lists (in the standard) and hash
>tables (not in the standard.)  How many people are going to have to
>write hash tables.

 Not me. I'll just grab the PD copy. I may fiddle
with it.

>It seems to me that although they do not have to
>"reinvent the wheel", they still have to "reinvent the spokes."

 But, at this stage of the game, that is probably right.
The Standard is providing the initial framework. It would be
premature to fill out that framework too much. Perhaps
"presumptuous" would be a stronger word.

 Although he's not always succeeded, Bjarne has
always tried hard NOT to be presumptuous. Perhaps thats why
there was no standard library containers in earlier C++.

 Now, today, with STL, that is perhaps a good thing.
It is bad enough to live with legacy designs like iostreams.

--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,
        81A Glebe Point Rd, GLEBE   Mem: SA IT/9/22,SC22/WG21
        NSW 2037, AUSTRALIA     Phone: 61-2-566-2189

In <D6Dr03.IMG@ucc.su.OZ.AU> maxtal@Physics.usyd.edu.au (John Max
Skaller) writes:

>
>In article <ncmD64z46.9n9@netcom.com>, Nathan Myers <ncm@netcom.com>
wrote:
>>In article <3l2evl$e7n@ixnews1.ix.netcom.com>,
>>Marian Corcoran <mcorcora@ix.netcom.com> wrote:
>>>As I get more deeply into STL, I am impressed by the creativity and
>>>hard work that has gone into its development.  The concept of an
>>>abstract data type is realized.  However, I also have the sense of
>>>stepping into a well constructed house, obviously designed by a
>>>brilliant architect, that is not finished.  Is there more?
>>
>>This is a very good question.
>
> To which the answer is "YES" :-)
>>
>>according to the pattern.  Moreover, some of us will establish other
>>interfaces as lists of requirements, in the same vein as STL, to
address
>>other domains.
>
> Yes. STL basically only deals with "sequences".
>They're not that much use for graphics, for example. But one
>can easily envisage a 2 dimensional version of STL --
>bootstrapped by STL of course.
>
> I'm reminded of Bertrand Meyer's comments on modules:
>A module has to be open for extension and closed for use --
>at the same time. Meyer derived the notion of classes from those
>requirements.
>
> But STL fits the same bill

While I,of course, would want STL to be extensible, I was surprised not
to find more.  A more extensive data structures class library, where one
could override the existing data structures and algorithms,  would be of
great help to programmers (especially those starting to use STL.)  I
remember reading in D & E, that Stroustrup was designing C++ with an
awareness of how people learn.  I also remember reading an article by
Stroustrup ("History of C++" in a History of Programming Languages
conference, I believe) where he stated that, looking back, he wished he
had built a data structures class library for C++, because he sees
people "reinventing the wheel."  The other day on the net, someone
expressed an interest in STL for lists (in the standard) and hash
tables (not in the standard.)  How many people are going to have to
write hash tables.  It seems to me that although they do not have to
"reinvent the wheel", they still have to "reinvent the spokes."

Marian
>--
>        JOHN (MAX) SKALLER,
INTERNET:maxtal@suphys.physics.su.oz.au
> Maxtal Pty Ltd,
>        81A Glebe Point Rd, GLEBE   Mem: SA IT/9/22,SC22/WG21
>        NSW 2037, AUSTRALIA     Phone: 61-2-566-2189
>

In <D6HrAD.6rt@research.att.com> bs@research.att.com (Bjarne Stroustrup)
writes:

..

I wish to thank Bjarne Stroustrup for his insights into STL.  While I
still have a strong intuitive sense that STL should be deeper, wider, I
will put that aside for now.  Stroustrup has worked long and hard on
C++, and I understand his wanting a standard.
     I apologize if my inquiry was ... I can't find the right words here
.. but I was sincerely struggling with and trying to work through some
issues on STL.  My concerns were and still are genuine.  ( There are so
many articles on the net.  I was surprised Stroustrup even noticed the
couple I wrote.)  Throughout those couple of articles though, I
continued to express my admiration for the brilliant and innovative work
done on STL.  It is certainly a major contribution to data structures
class library technology, further along than I would have expected.  I
also expressed my appreciation for the creative developments in C++
which have made important contributions to the field of programming
languages.  Certainly Stroustrup's groundbreaking work will have a major
impact for years to come.

Marian

mcorcora@ix.netcom.com (Marian Corcoran) writes

 > While I,of course, would want STL to be extensible, I was surprised not
 > to find more.  A more extensive data structures class library, where one
 > could override the existing data structures and algorithms,

The STL is extensible, very extensible, but that has nothing to do with
``overriding existing data structures and algorithms'' whatever that might
mean. You can add algorithems and data structures to the STL, and replace
the ones provided by the standard by improved implementations. What one
cannot do is to selectively modify the data structures and algorithms
provided by the standard through virtual function overriding.

This may urprise people who hasn't gotten used to the STL and still thinks
in terms of libraries organized as class hierarchies, but it is not necessarily
a bad thing. In fact, I think it is a good thing, because I have found
class-hierarchy-based foundation libraries too constrainingand too inefficient
for many critical uses (though of course not for anything like all uses).

In other words, I find the STL more flexible and extensible than other
foundation frameworks/libraries providing the classical data structures
and their fundamental algorithms. One initially surprising thing is how
concepts from other foundation libraries not directly supported by the
STL can be fitted into the STL framework. Examples are range-checked
sequences and modification of classes through overriding.

The STL as provided by the standard is not small.

Here is one way of summarizing it:

 Standard containers:

  vector<T>
   vector<bool>
  list<T>
  deque<T>
  stack<T>
  queue<T>
  priority_queue<T>
  set<T>
  multiset<T>
  map<K,V>
  multimap<K,V>

 Standard iterators:

  random_access_iterator
  forward_iterator
  backward_iterator
  bidirectional_iterator
  istream_iterator
  ostream_iterator
  ...

  (in all 11 iterators plus supporting classes )

 Standard algorithms:

  copy()
  binary_search()
  count()
  find()
  for_each()
  merge()
  partial_sort()
  remove_if()
  reverse()
  stable_sort()
  transform()
  ...

  (In all 62 algorithms)

My experience has been that more people are overwhelmed by the sheer
scale of what is provided than there are people who soon ask for more
- and those who ask for more often simply ask for the familiar without
noticing that an equivalent is already provided.

The part of the STL framework that is filled in for the standard is not
random, it is a set determined by looking at real use of data structures
and algorithms in C++ foundation libraries and foundation libraries for
other languages.

 > would be of
 > great help to programmers (especially those starting to use STL.)  I
 > remember reading in D & E, that Stroustrup was designing C++ with an
 > awareness of how people learn.  I also remember reading an article by
 > Stroustrup ("History of C++" in a History of Programming Languages
 > conference, I believe) where he stated that, looking back, he wished he
 > had built a data structures class library for C++, because he sees
 > people "reinventing the wheel."  The other day on the net, someone
 > expressed an interest in STL for lists (in the standard) and hash
 > tables (not in the standard.)  How many people are going to have to
 > write hash tables.  It seems to me that although they do not have to
 > "reinvent the wheel", they still have to "reinvent the spokes."

I think that analogy is flawed, and in my opinion STL provides so much
that is is probably also unfair. I too would like to see hashed containers
in the standard, but most of all I want to see a standard: complete,
polished, signed and sealed! If adding hashed contained gets in the way
of that goal, I'll do without hashed containers in the standard.

I happen to think that we could have hashed containers and a standard
without delay, but not everyone agrees and whatever the standard says
we DO have hashed containers. A really nice design was presented to the
committee and its definition and - I think - two good implementations
so far exists in the public domain. The extensibility of the STL is nicely
demonstrated by the fact that whatever the standard says, I'll write my
next major program using hashed containers.

One reason, I didn't provide a standard container library - even though
I was well aware of the need - in the early releases of C++ was that I
didn't know how to build one that fulfilled enough of my criteria for
a standard library. The structure of the STL surprised me too, but it
fulfilled far more of my criteria than any other I have seen so far.

Importantly, I have found that many people learn the STL faster than most
other libraries of a similar magnitude. What we need most is more tutorial
material of a caliber worthy of the STL.

 - Bjarne

In article <ncmD64z46.9n9@netcom.com>, Nathan Myers <ncm@netcom.com> wrote:
>In article <3l2evl$e7n@ixnews1.ix.netcom.com>,
>Marian Corcoran <mcorcora@ix.netcom.com> wrote:
>>As I get more deeply into STL, I am impressed by the creativity and hard
>>work that has gone into its development.  The concept of an abstract
>>data type is realized.  However, I also have the sense of stepping into
>>a well constructed house, obviously designed by a brilliant architect,
>>that is not finished.  Is there more?
>
>This is a very good question.

 To which the answer is "YES" :-)
>
>according to the pattern.  Moreover, some of us will establish other
>interfaces as lists of requirements, in the same vein as STL, to address
>other domains.

 Yes. STL basically only deals with "sequences".
They're not that much use for graphics, for example. But one
can easily envisage a 2 dimensional version of STL --
bootstrapped by STL of course.

 I'm reminded of Bertrand Meyer's comments on modules:
A module has to be open for extension and closed for use --
at the same time. Meyer derived the notion of classes from those
requirements.

 But STL fits the same bill -- it is closed for
use by the Standardisation process and open for extension
as Nathan has described. And this is why it is particularly
important to actually _Standardise_ it.

--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,
        81A Glebe Point Rd, GLEBE   Mem: SA IT/9/22,SC22/WG21
        NSW 2037, AUSTRALIA     Phone: 61-2-566-2189

In <ncmD64z46.9n9@netcom.com> ncm@netcom.com (Nathan Myers) writes:

>
>In article <3l2evl$e7n@ixnews1.ix.netcom.com>,
>Marian Corcoran <mcorcora@ix.netcom.com> wrote:
>>As I get more deeply into STL, I am impressed by the creativity and
hard
>>work that has gone into its development.  The concept of an abstract
>>data type is realized.  However, I also have the sense of stepping
into
>>a well constructed house, obviously designed by a brilliant architect,
>>that is not finished.  Is there more?
>
>This is a very good question.
>
>
Although N. Myers made some interesting points, I think he misunderstood
the main point of my posting.  According to C++ Report (Vilot, October
(?), 1994), only a subset of Stepanov and Lee's work was admitted to the
standard. Although I do not wish to be critical of the decision, I was
expressing my concern.  Basically, I was asking for the matter to be
reconsidered on the grounds that by reinstating what was omitted would
make C++ easier for professional programmers to use.
     I also wish to restate that I value and admire that hard work that
members of the committee and others are performing in their efforts to
create a standard.

M. Corcoran
Advanced C++ SIG Chair
Software Forum
Palo Alto, CA


>

In article <3l2evl$e7n@ixnews1.ix.netcom.com>,
Marian Corcoran <mcorcora@ix.netcom.com> wrote:
>As I get more deeply into STL, I am impressed by the creativity and hard
>work that has gone into its development.  The concept of an abstract
>data type is realized.  However, I also have the sense of stepping into
>a well constructed house, obviously designed by a brilliant architect,
>that is not finished.  Is there more?

This is a very good question.

In one sense, most of what is in STL is "extra": all the algorithms,
and all the data structures, could have been left out, and it would
be complete.  That is, it is the requirements lists for iterators
and containers that is the fundamental advance; the other stuff is
just examples, and proofs of concept.

In another sense, it will never be finished.  As M. Corcoran notes,
we will all write new containers, algorithms and iterators
according to the pattern.  Moreover, some of us will establish other
interfaces as lists of requirements, in the same vein as STL, to address
other domains.  Certainly STL as standardized doesn't cover the entire
field of undergraduate CS: the model has already been extended for hash
structures, and undoubtedly will be for general graphs and for
algebraic fields (cf. Barton & Nackman).  I expect the design and
refinement of such interfaces to become an active field of inquiry
in SW engineering, and support for such activity an important part
of future language design.

Nathan Myers
myersn@roguewave.com

As I get more deeply into STL, I am impressed by the creativity and hard
work that has gone into its development.  The concept of an abstract
data type is realized.  However, I also have the sense of stepping into
a well constructed house, obviously designed by a brilliant architect,
that is not finished.  Is there more?

     I know Stepanov created more, but only part was accepted by the
ANSI committee.  I believe there are several factors at work here.

1.  There is a basic principle of being    lean   .  However, does that
principle necessarily lead to the creation of the best programming
language?
2.  There is also a concern of how much should be covered.  In the
instance of a data structures and algorithms class library, the scope of
what is covered in a graduate level data structures and algorithms text
would probably be a reasonable coverage.  Even if the user decided to
write their own version of a certain algorithm (and override the one
provided), the one in the library could serve as a model to make this
easier.
3.  I also sense an urgency to get things finished (i.e. standardized).
 Some of the software engineering community has not been quite fair to
the committee.  Those serving on the committee work long, hard hours.
Many of you who read this are programmers.  How would you feel if, after
putting in 80 hours a week to get work done, your manager came to you
and said    Aren   t you finished yet?

In an ideal world, we would be able to split programmers into two
groups, one with the current STL, and one with what Stepanov originally
created.  We could then see which group was more productive (with
respect to design, coding, maintainability, etc.)

It is not my intention to criticize the decision made on STL, but only
to question it.  My perspective is one of a professional software
engineer and also that of an instructor of professional programmers.  I
see the types of things they struggle with as they learn C++.  It is a
rich, powerful language.  I would like to see more    guidance    built into
it for its use in the early stages of a persons working with it.  For
example, if there were more algorithms built into STL, I would expect
software engineers to rely on them more in the beginning, but later
would be more inclined to create their own (and could as long as they
follow the requirements for    genericity   .)

I value and admire the work that has gone into the development of C++
and STL.  I also appreciate those on the USENET who take the time to
answer questions and help others learn.

mc