Re: Standard library exception specifications might be lacking
on Sat Sep 22 2007, rani_sharoni-AT-hotmail.com wrote:
On Sep 21, 11:10 pm, gre...@pacbell.net (Greg Herlihy) wrote:
So a C++ programmer does not have to
wonder whether a particular Standard Library routine throws exceptions or
not - because they can always consult their library's documentation to find
out for certain.
Maybe the motivation for my request will clarify my reasoning
regarding usability and testability.
Recently I discovered that the VC-STL implementation of std::vector
default constructor was changed to enable debugging feature in
production code (i.e. "secure iterators") and now it can throw.
Obviously it's possible to implement such feature without changing the
no-fail guarantee that the implementation *always* use to have.
Nevertheless I was informed that the standard doesn't forbid vector's
default constructor from throwing so that code that *assumed* no-fail
guarantee is anyway broken.
I think that abusing the standard in such way is not fair
I think calling that "abuse of the standard" is an unfair
characterization.
and hopefully clarifying the standard
I am sorry that you were surprised by this, but I think the standard
is perfectly clear on this point. I agree that it could provide
stronger guarantees, and that making these guarantees would be useful.
I would even agree that as a matter of quality-of-implementation, that
particular implementation should never throw from its default
constructor, and in fact I'm very surprised to hear that it can.
will make it easier to write correct, portable and testable code in
respect to the standard itself and not specific implementation that
might introduce breaking changes.
IMHO, the fact that many operations never threw in practice gives
good indication that they should have no-fail guarantee since
otherwise the specifications might be exploitable by sloppy
implementation without being accountable for breaking innocent
clients claiming that such clients were always "broken".
They were, in terms of portability, "always broken." It's no
different from relying on any other assumption that depends on a
particular C++ implementation.
Incidentally, if you want the other committee members (among the most
influential, the authors of that STL implementation to which you
refer) to be favorably disposed to a proposal strengthening
guarantees, it might be a good idea not to accuse them of standards
abuse. While these particular guys have an admirable ability to
remain objective, everyone has his limits.
--
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]