James Kanze US/ESC 60/3/141 #40763 <kanze@lts.sel.alcatel.de> wrote:

>Safer implementations are possible; Cay Horstman, I think, has already
>made one available.

Indeed. It works nicely as a debugging tool, and is 100% compatible
with plain STL. Think of it as an "assert" for STL. It is available
from http://www.mathcs.sjsu.edu/faculty/horstman/safestl.html. A
number of people at NYU have ported it to g++. If there is interest,
I'll find out how far they got.

>Exception safe implementations are also possible.
>(It is also an open question how far one wants to go here.  I would
>accept, for example, that an exception from the comparison function
>when inserting into a map results in undefined behavior; if comparison
>can throw an exception, an STL map is perhaps not the appropriate
>container.)

I am not sure exceptions are the way to go--the great value of a
standard is that it is, well, standard. STL may not be the greatest
library on the planet, but it is certainly good enough, and it is
standard. I don't like the idea of tinkering with the interface by
adding exceptions.

My model here is the C string.h library. Consider strncpy. Could you
imagine a dumber function? If either of the arguments is null, it
dumps core. 99% of strncpy uses in my programs are of the form
 strncpy(buffer, s, sizeof(buffer));
 buffer[sizeof(buffer) - 1] = 0;
Sure, in 1% of the cases, I am glad it doesn't add the terminating 0,
but in 99% of the cases I hate it. But did I go out and write my own
superior replacement of strncpy? I did for a while and all of my team
members protested. They didn't want to learn my pet library. So I am
back to strncpy. Like Bjarne Stroustrup wrote, library design is
language design.

Same with STL. I'd rather not figure out subtle differences between
customized STL versions, especially with something as subtle as
exception specifications. If it is a good idea for STL to throw
exceptions when the user inserts something stupid, then let's lobby to
make that a part of the standard. Otherwise put the test in the user
code, not into a custom STL.

Cay
horstman@cs.sjsu.edu
---
[ 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. ]

> ==========Steve Karmesin, 1/19/96==========

> Micha Berger wrote:
> ....snip...

> First, I will dispute the claim that something like the STL is not OO.
> Second, even if it was not that doesn't make it a bad part of C++.

> The fact that the algorithm of the STL aren't tied to particular data
> structures does not mean that it is not OO. A better OO
language than C++
> would in fact allow the algorithms themselves to be objects. The
> fact that
> they are written as templates rather than classes in C++ is because of
> limitations in C++, not limitations in the idea of objects.
> Object != class.
>
> I would say that the STL is a big help in OO design, even if the
> algorithms
> aren't considered to be objects themselves.

Actually, the templated algorithms are more at the
level of meta-object patterning.  If strict OO does
not allow you to get up out of the furrow you are
digging to see larger pictures, then strict OO has
a serious problem of too narrow a vision of the
problem space.

Being able to explicitly codify generic forms is
an essential part of good OO.  It sounds like
people want everyone to reinvent the wheel
for some misplaced notion of purity.

Good Day
Dick
Dick.Menninger@DaytonOH.ATTGIS.COM
---
[ 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. ]

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

In article <4du1v6$h74@jupiter.SJSU.EDU> horstman@jupiter.SJSU.EDU (Cay
S. Horstmann) writes:

> James Kanze US/ESC 60/3/141 #40763 <kanze@lts.sel.alcatel.de> wrote:
>
> >Safer implementations are possible; Cay Horstman, I think, has already
> >made one available.
>
> Indeed. It works nicely as a debugging tool, and is 100% compatible
> with plain STL. Think of it as an "assert" for STL. It is available
> from http://www.mathcs.sjsu.edu/faculty/horstman/safestl.html. A
> number of people at NYU have ported it to g++. If there is interest,
> I'll find out how far they got.

Is it just for debugging.  I would imagine that one would be using this
version most of the time, in preference to something more dangerous, and
only abandon it when profiling showed that it was necessary.

> >Exception safe implementations are also possible.
> >(It is also an open question how far one wants to go here.  I would
> >accept, for example, that an exception from the comparison function
> >when inserting into a map results in undefined behavior; if comparison
> >can throw an exception, an STL map is perhaps not the appropriate
> >container.)
>
> I am not sure exceptions are the way to go--the great value of a
> standard is that it is, well, standard. STL may not be the greatest
> library on the planet, but it is certainly good enough, and it is
> standard. I don't like the idea of tinkering with the interface by
> adding exceptions.

Exceptions cannot be avoided.  If the behavior of STL is declared
undefined if an object of the instantiation type throws an exception,
for example, then it becomes practically unusable.  Most of my objects
will acquire dynamic memory, and operator new may throw an exception.

This is not tinkering with the interface, this is a standards question:
what is the defined behavior of, e.g.: vector< T > if T throws an
exception?  What is the state of

 vector< T >   v( 5 ) ;

if the third call to T::T( T const& ) (to initialize v[ 2 ]) causes an
exception to be thrown.

In the current (HP) implementation, v[ 0 ] and v[ 1 ] will have been
fully constructed; v[ 2 ] presumably will have coped correctly to appear
unconstructed, and v[ 3 ] and v[ 4 ] are just chunks of raw memory.

IMHO, for example, in the above case, it should be explicitly stated
that the entire array is just raw memory.  (Note that because the
exception propagates up out of the constructor of vector< T >, before
the constructor has finished, the corresponding destructor will not be
called.)  The user has *no* way of doing proper clean-up.

> My model here is the C string.h library. Consider strncpy. Could you
> imagine a dumber function? If either of the arguments is null, it
> dumps core. 99% of strncpy uses in my programs are of the form
>  strncpy(buffer, s, sizeof(buffer));
>  buffer[sizeof(buffer) - 1] = 0;
> Sure, in 1% of the cases, I am glad it doesn't add the terminating 0,
> but in 99% of the cases I hate it. But did I go out and write my own
> superior replacement of strncpy? I did for a while and all of my team
> members protested. They didn't want to learn my pet library. So I am
> back to strncpy. Like Bjarne Stroustrup wrote, library design is
> language design.
>
> Same with STL. I'd rather not figure out subtle differences between
> customized STL versions, especially with something as subtle as
> exception specifications. If it is a good idea for STL to throw
> exceptions when the user inserts something stupid, then let's lobby to
> make that a part of the standard. Otherwise put the test in the user
> code, not into a custom STL.

I agree.  The present situation is that there is one aspect of the
interface definition which has not been defined.  In order to be useful,
it must be.
--
James Kanze           (+33) 88 14 49 00          email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs Bourgeois, 67000 Strasbourg, France
Conseils, itudes et rialisations en logiciel orienti objet --
              -- A la recherche d'une activiti dans une region francophone
---
[ 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. ]

Related to the apparent "un-object-orientedness" of STL, one problem we've
run into is the inability to gracefully store abstract objects in a container.

One solution is to wrap the object to be stored in some sort of handle.
For those who like to wrap everything in a "handle", this works well.  For
others, this is quite an inconvenience.

Another solution is to use a container of pointers-to-T.  This, however,
makes for some ugly and dangerous code.

Our solution was to create the templates ``plist'', ``pvector'',
``pset'', etc.  These are containers that meet the requirements of
``list'', ``vector'', etc., but internally use pointers instead of
actual copies of the objects.

We've extended the role of the allocator to include ``T* make_default()'' and
``T* make_copy(const T&)'' functions.  This way, a ``plist<T>'' (for example)
can meet all the requirements of a ``list<T>'', even if T lacks an actual
default ctor or a copy ctor.

Often, We've found that make_copy is defined as ``{ return t.replicate(); }'',
where ``T* replicate()'' is a virtual function for duplicating and returning a
pointer to the new copy.  We do this so often that, in our plist.h, we
have a:
   template<class T> class plistB<T> : public plist<T,p_allocatorB<T> > {...};
where ``p_allocatorB<T>'' assumes T has a ``replicate'' member function, and
that T cannot be default constructed.  Note that, due to lack of a default
constructor, plistB<T> can't do everything that list<T> can, but this is
usually not a problem.

Also, we have an p_allocatorA<T> which simply does a ``{ return new T(t); }''
for make_copy(), and a ``{ return new T; }'' for make_default().  Our
``plistA<T>'' uses this allocator (our compiler doesn't support default
template args).


We are currently adding some special iterator tags to determine if the
iterator is to one of our "p*" containers.  Using these tags, we should
be able to speed up those algorithms that move elements around within or
between containers (since moving a pointer is almost always faster than
moving an object).  The "p*" container iterators offer the following
additional functions:
    T* get_p();                 // These should always be used together
    void set_p(T*);             //  "
and the "plist" (for example) offers:
    void push_back_p( T* p );                     // ``p'' is deletable
    void push_front_p( T* p );                    //  "
    iterator insert_p(iterator position, T* p );  //  "
    T* pop_back_p();                // Caller must worry about deleting
    T* pop_front_p();               //  returned value.
    T* erase_p(iterator position);  //  "
All of the above (slightly dangerous) extensions transfer "ownership" of
a deletable pointer between caller and callee.  These extensions are
primarily for use by well-tested algorithms.  The general user would
typically stick to the basic set of (safe) STL-defined routines.


Maybe by using something like this, the original poster would find
STL more OO-friendly.

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

In article djk@rc1.vub.ac.be, Alain Dresse <adresse@ulb.ac.be> writes:
>I have heard about considerations on removing STL from the
>C++ standard because it is error prone.

>Could anyone confirm or deny this information ?

False.

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.

---
Steve Clamage, stephen.clamage@eng.sun.com
Chair, X3J16, C++ Committee
---
[ 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. ]

I have heard about considerations on removing STL from the
C++ standard because it is error prone.

Could anyone confirm or deny this information ?

If this is the case, what would be considered to replace STL ?

Alain Dresse
adresse@ulb.ac.be
---
[ 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. ]

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 don't like STL because it represents an abandonment of one of C++'s
strengths, the tools for implementing an object oriented design.

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.

--
Micha Berger 201 916-0287        Help free Ron Arad, held by Syria 3255 days!
AishDas@haven.ios.com                     (16-Oct-86 -  5-Oct-95)
<a href=news:alt.religion.aishdas>Orthodox Judaism: Torah, Avodah, Chessed</a>
<a href=http://haven.ios.com/~aishdas>AishDas Society's Home Page</a>
---
[ 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. ]

In article <4dj7eu$2sp@news.ios.com> aishdas@haven.ios.com (Micha Berger)
writes:

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

It's true that STL isn't an object-oriented library; it was never
supposed to be.  It enables generic programming, which is a valuable
technique in its own right.

There's no reason why every C++ library should be object-oriented: The
design goal of C++ has always been to support object-oriented
programming, but to support other styles of programming too.  Bjarne
Stroustrup discusses this in great detail in D&E.
--
Matt Austern
SGI: MTI Compilers Group
austern@isolde.mti.sgi.com
---
[ 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. ]

In article <4dgrb4$a2e@engnews1.Eng.Sun.COM> clamage@Eng.Sun.COM
(Steve Clamage) writes:

|> In article djk@rc1.vub.ac.be, Alain Dresse <adresse@ulb.ac.be> writes:
|> >I have heard about considerations on removing STL from the
|> >C++ standard because it is error prone.

|> >Could anyone confirm or deny this information ?

|> False.

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

That's what I want to hear.

I'm curious in what way the STL is error prone.

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

Micha Berger wrote:
...snip...
>
> I don't like STL because it represents an abandonment of one of C++'s
> strengths, the tools for implementing an object oriented design.
>
> 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.
...snip...

First, I will dispute the claim that something like the STL is not OO.
Second, even if it was not that doesn't make it a bad part of C++.

The fact that the algorithm of the STL aren't tied to particular data
structures does not mean that it is not OO. A better OO language than C++
would in fact allow the algorithms themselves to be objects. The fact that
they are written as templates rather than classes in C++ is because of
limitations in C++, not limitations in the idea of objects. Object != class.

I would say that the STL is a big help in OO design, even if the algorithms
aren't considered to be objects themselves.

In any case, C++ is a language for making programs. One of the tools it puts
in the hands of the programmer is objects and some facilities for doing
object oriented design.

The goal is not and should not be to build an object oriented language. The
goal should be to build a language in which people can solve problems. An
object oriented language and object oriented design are ways to do that, but
they are not the only ways.

If what you want is a teaching tool or research tool to explore the limits
of strict object oriented desing, such languages exist but those are not the
goals of C++.

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