Dinkum C++ Library exception safety
P.J. Plauger
> Subject: Re: BUGS in Dinkumware STL and the new book by Plauger on the C++ STL
> Date: Thursday, April 05, 2001 9:51 PM
>
> I know the Dinkum team to be conscientious developers. If they had used my
> test, they would have found the bugs, and I'm sure they would have fixed
> them. I guess it's possible that the code being referred to is pre-standard,
> though. Does anyone know for sure?
I'm back from the Embedded Systems Conference now and can address the issues
raised by Dave Abrahams and Andrei Iltchenko.
First, the book I wrote with Alex Stepanov, Meng Lee, and Dave Musser does
contain
some errors, both in the code and in the descriptions of exception safety. These
things happen despite careful review by the authors and other helpful and
knowledgable
people. The code and documentation currently shipped by Dinkumware have both
long since corrected most of the errors. I just found a few more this past week.
I fully expect to find more in the coming months and years. Anybody who expects
otherwise doesn't understand the realities of writing and maintaining a complex
software product.
I downloaded the latest version of the Abrahams exception-safety tests just
before
my trip, and have spent most of my spare time on the road getting them to work.
They do *not* test a conforming C++ library for proper behavior in the presence
of exceptions. Rather, they are written to test STLport, and a couple of
derivatives
from specific vendors, for behavior closely resembling what is required by the
C++
Standard. It took me several hours work to extend and correct the tests just to
work
with a properly conforming library.
Most of the remainder of my time went to debugging the tests themselves. They
are full of presumptions and outright errors. The tests for bitset are vacuous,
yet
still manage to contain a bug(!) The tests for valarray are lunchmeat -- someone
copied the string tests, then never made all the changes needed to adapt them.
I had to modify the tests for hash_{multi}[map set], of course, because they are
not standardized. Miraculously, the test for slist, also nonstandard, mostly
worked
out of the box.
In the end, I got all the tests to run properly with the Dinkum C++ Library. I
skipped
the tests for rope, also nonstandard, which we have yet to implement. I found
and fixed a few bugs in our library, as I mentioned above. I also beefed up our
deque insert to pass an overly stringent test for which I could find no
justification
in the C++ Standard. Finding those few bugs justified the cost of the effort. It
also
doesn't hurt that we can now quell the concerns raised earlier in this thread.
Our
library as currently shipped behaves very well in the presence of exceptions.
Future versions will work even better.
P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
[ about comp.lang.c++.moderated. First time posters: do this! ]
David Abrahams
"P.J. Plauger" <p...@dinkumware.com> wrote in message
news:3ad717c2$0$81...@wodc7nh7.news.uu.net...
> I downloaded the latest version of the Abrahams exception-safety tests
just
> before
> my trip, and have spent most of my spare time on the road getting them to
work.
> They do *not* test a conforming C++ library for proper behavior in the
presence
> of exceptions. Rather, they are written to test STLport, and a couple of
> derivatives
> from specific vendors, for behavior closely resembling what is required by
the
> C++
> Standard.
That is true. They were written pre-standardization and have never been
updated (I have always had employers who wanted other work from me and would
pay a salary ;-))... they're also kind of crufty having been maintained only
sporadically and could use a good rewrite. As Bill writes, however, the
behavior they check for "closely resembles" the behavior required by the
standard, so they will find most problems, including the ones Andrei pointed
out.
> It took me several hours work to extend and correct the tests just to
> work
> with a properly conforming library.
That's fast work! If I thought I could have done it that fast I probably
would have by now.
> Most of the remainder of my time went to debugging the tests themselves.
They
> are full of presumptions and outright errors. The tests for bitset are
vacuous,
> yet
> still manage to contain a bug(!) The tests for valarray are lunchmeat --
someone
> copied the string tests, then never made all the changes needed to adapt
them.
Some of the tests were added or extended by other people and I haven't
maintained careful control over the code, FWIW.
> I had to modify the tests for hash_{multi}[map set], of course, because
they are
> not standardized. Miraculously, the test for slist, also nonstandard,
mostly
> worked
> out of the box.
>
> In the end, I got all the tests to run properly with the Dinkum C++
Library. I
> skipped
> the tests for rope, also nonstandard, which we have yet to implement. I
found
> and fixed a few bugs in our library, as I mentioned above. I also beefed
up our
> deque insert to pass an overly stringent test for which I could find no
> justification
> in the C++ Standard.
Like I said, the tests are pre-standard. We were still working out what the
exception guarantees should actually be.
> Finding those few bugs justified the cost of the effort.
I'm glad. I don't suppose you'd like to contribute the revised tests back to
the community?
-Dave