TITLE: STL and exception and pointer safety

[ This thread picks up on a discussion of STL (the standard template
  library that is now part of the C++ Draft Working Paper) concerning
  pointer safety and exception saftey. -adc ]

Nagle: nagle@netcom.com (John Nagle)

       We knew STL wasn't pointer safe, but it isn't exception safe
either?   Maybe it's time to look for a replacement.  Extending
pointer arithmetic as a model for iterators wasn't, in retrospect,
such a hot idea.


Bjarne: bs@research.att.com (Bjarne Stroustrup), 11 Feb 96

I (still) think the STL is a great idea. In fact, it is the only library
I have seen that remotely fulfills my criteria for what a standard library
of containers and their common uses should be.

You can use the STL in ways that gives you bad pointers. However, it is
far easier to avoid that than it is when you are using the bare language.
Simply referring to that as "isn't pointer safe" is accurate, but
potentially misleading. If you wan't pointer safety, you can relatively
easily achieve it within the framework of the STL. The converse operation
- gaining close to optimal performance and freedom to control key policy
decisions from a safe library - is not (to my knowledge) feasible.

Calling the STL "not exception safe" is IMO inaccurate. The STL itself
doesn't throw exceptions and it doesn't try to intercept and mask out
exceptions thrown by its users. That is deliberate, and I think, the
right thing for a standard library to do. Imposing a non-trivial error
handling policy (for every user) isn't feasible for a standard library.

The STL doesn't try to catch memory management exceptions. Similarly, no
standard library facility attempts to protect the user from that or other
systems-realated problems such as arithmetic overflow or signals. In a
language as close to the machine as C and C++, there is little else one
can do for the standard library.

People can look for replacements for their own code, but the STL is in the
standard to stay. I hope that "replacements" will be built on the STL and
wherever possible within the framework of the STL (thus being enhancements
rather than replacements). Breaking the standard mold should not be done
unless absolutely necessary. Having a standard and common container,
iterator, and algorithms framework is far more useful than any minor
improvement.

An analogy: the C standard library is arguably not the best C foundation
library of its kind; it is arguably not even the best such library that
was available at the time. However, it was good enough, and its close-to-
universal acceptance was a major contributor to C's success. The STL is
better than just good enough.

Nagle:

       Take a look at the iterator classes that come with MetroWerks
CodeWarrior.  They seem to be a big improvement on STL.  You can even
do things like remove elements from the list you're iterating over
without breaking anything, although there's more machinery behind
this than some might like.  It's not one of those "everything descends
from Object" libraries, either.

Bjarne:

I haven't seen the CodeWarrior library, but it sounds as if I ought to
have a look. However, I suspect that however great it is, it will have
limitation as a STANDARD library (for example, platform dependence,
built-in policies, commercial restrictions, non-minimal space overheads,
or efficiency limitations). Anyway, I see no point in re-opening the
standard library debate at a fundamental level and I'm sure the vast
majority of standards committee members agree.