Francis Glassborow wrote in message <4rRZwUBaFSk2EwF5@robinton.demon.co.uk>...
>
>In article <368fedf3@news.newsfeeds.com>, Alex Martelli
><alex@magenta.com> writes
>>The wide mis-application of this "STL" monicker is, IMHO, one
>>of the reasons to wish its use could be stamped out altogether
>>(given the inexplicable fascination on the human mind of three
>>letter acronyms, this is, of course, strictly in the "if wishes were
>>horses" category:-).

I will resist such stomping until an equally succinct
term for the same concept is in common usage or
a better term appears destined for common usage.

>So what would you suggest?  You see, for some of us, STL describes a
>very specific set of generic items (containers, algorithms and
>iterators) that work together to achieve certain ends.  An STL container
>works with an STL algorithm though the intermediacy of an STL iterator.
>I know what to expect if a competent programmer states that a hash table
>implementation conforms with the STL concept etc...  We need a name for
>this kind of generic programming tool.

Yes, we certainly do.  I suggest that "STL", expanded
to "standard template library" works just fine.  It remains
meaningful for the original STL, apart from C++, and
has no fatal ambiguity in connection with C++.

We need not worry that the word "template" seems to
encompass every template specified for C++ since
most of them outside of the STL are implementation
details anyway rather than templates offered by the
libarary for arbitrary instantiation.  I think people are
sometimes getting snared by separating "template"
from "libary", then recombining as "templates found
in the standard libary."  The simpler, obvious reading
is "template library".

Where an algorithm or container is designed to
adhere to the STL requirements, I see no real
confusion arising from claims such as "This
is a model of an STL Sorted Associative
Container."  (Credit to Matt Austern's concept
work in "Generic Programming and the STL".)

Where people refer to the whole "STL", without
distinguishing its aspects, it is harmless if a few
listeners think that also includes std::complex<>
and a smattering of other little library templates.

When people refer to particular aspects of the STL,
it should be clear from context that the referent is
what might be (much too) verbosely named the
"C++ Combinable Container and Algorithm Library".

As Francis asserts, we need to be able to refer
to the CCCAL in detailed technical discussion.
Unlike Mr. Clamage, I think calling it "STL" is a
good idea and that attendant confusion is either
harmless or will subside as usage is established.

--Larry Brasfield
Above opinions may be mine alone.
X-Replace-Address
(Humans may reply at unundered larry_br@sea_net.com )



[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Larry Brasfield <larrybr@seanet.com> wrote:


: Yes, we certainly do.  I suggest that "STL", expanded
: to "standard template library" works just fine.  It remains
: meaningful for the original STL, apart from C++, and
: has no fatal ambiguity in connection with C++.

[snip other well stated comments]

Agreed!  STL should mean "containers, iterators, algorithms".  The
entire C++ library should be refered to as SL (standard library).  Much
of the SL is templated; however, the STL existed prior to the standard
in a somewhat different form.

Bonnard has introduced the possibility that string might now be
considered part of STL since it conforms to the container requirements.
I can accept that, but not streams just because iterators exist.

John



[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <76s767$m4h$1@pigpen.csrlink.net>,
  jpotter@falcon.lhup.edu (John Potter) wrote:
>
> Larry Brasfield <larrybr@seanet.com> wrote:
>
> : Yes, we certainly do.  I suggest that "STL", expanded
> : to "standard template library" works just fine.  It remains
> : meaningful for the original STL, apart from C++, and
> : has no fatal ambiguity in connection with C++.
>
> [snip other well stated comments]
>
> Agreed!  STL should mean "containers, iterators, algorithms".  The
> entire C++ library should be refered to as SL (standard library).  Much
> of the SL is templated; however, the STL existed prior to the standard
> in a somewhat different form.

I prefer STD over SL (just makes sense to me with the std namespace).  I also
disagree with using STL for any part of the STD.  There are still people using
the real STL, and as you pointed out there are some important differences
between the real STL and the parts that were included in the STD.

> Bonnard has introduced the possibility that string might now be
> considered part of STL since it conforms to the container requirements.
> I can accept that, but not streams just because iterators exist.

If you're going to make such distinctions, then why not include streams?  They
behave exactly like containers and are valid to use with the standard
algorithms.  What about them would exclude them?

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

sirwillard@my-dejanews.com writes:

> If you're going to make such distinctions, then why not include streams?  They
> behave exactly like containers and are valid to use with the standard
> algorithms.  What about them would exclude them?

Streams do not behave like containers.  A generic algorithm designed
to operate on types that conform to the Container requirements will
fail if it is passed a stream rather than a Container.

What is true is that stream iterators can be used (almost) the same
way as container iterators.  That's quite different.

(And, for what it's worth, I certainly would include stream and
streambuf iterators in any discussion of the STL.  Stream iterators
were part of the original Stepanov-Lee STL documentation.)
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]