🚀 go-pugleaf

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