🚀 go-pugleaf

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