Re: Standard library exception specifications might be lacking
On 9/20/07 1:39 PM, in article
1190304683.781001.318130@i38g2000prf.googlegroups.com,
"rani_sharoni@hotmail.com" <rani_sharoni@hotmail.com> wrote:
On Sep 17, 11:41 pm, d...@boost-consulting.com (David Abrahams) wrote:
In my implementation atop STLPort, the restrictions were often tighter
than what we ended up specifying for the standard
(http://tinyurl.com/32elac) so things like operator[] were usually
specified not to fail and the tests would check for that.
Judging by the implementation of existing libraries (e.g. VC-STL) the
implementation itself relay of the fact that some of the "might-fail"
operations can't fail. For example, vector::erase uses std::copy which
means that the later is assumed not to throw if T's ctor is not
throwing.
No, the library vendor is not assuming anything about std::copy()'s throwing
behavior. Having written the routine in question, the library vendor is in a
pretty good position to know for sure whether their implementation of
std::copy() ever throws exceptions on its own - or not. In case of VC++ (and
I would guess every other C++ compiler), std::copy() does not throw
exceptions, so the vendor is free to take advantage of that knowledge in the
implementation of the other library routines. And clients of this vendor's
library may do the same.
After all, if a particular implementation of std::copy() does throw
exceptions, then the vendor is obligated (according to 17.4.4.8/3) to
document the type of exception thrown. 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.
So the only effect of adding "no throw" clauses to existing Standard Library
functions would not be to provide any new information to C++ programmers.
Instead the only effect would be to inhibit the the discretion of library
vendors. If a library vendor goes to the trouble off having one of the
Standard Library routines throw an exception - then we can be fairly certain
that this behaior would be options (and would have to explicitly enabled by
the programmer) - and we can also be even more confident that the reason the
exception throwing behavior was added - was because a customer asked for it.
That's perfectly valid from the implementation POV but makes it
impossible to test whether the application is strictly compliant for
which std::copy "might fail" even for non-throwing T.
Of course it is impossible to test what would happen should std::copy() fail
- if it is impossible for std::copy() to fail in the first place.
I mentioned that above mainly to show in another way the importance of
reasonable specifications for the favor of usability and testability.
But not apparently in favor of correctness. The "testability" of software is
not an end in its own right; if it were - then we would see more programmers
trying to maximize the number of potential points of failure in their
programs - just to be able to have a test for each of them. In reality,
correctness is the goal of software programming, testability is a goal only
insofar as the tests measure the correctness of the software.
I'll be happy to file a defect report based on this discussion.
(Howard, please correct me if I'm wrong) I don't think it's
appropriate for a defect report, since we said exactly what we meant,
but I'd be happy to co-author a paper with you, proposing changes.
I thought that defect report is appropriate here since it's about
expectations for certain usability which is similar for the famous
"contiguous vector" DR.
There is no net gain to be realized simply by adding more throw clauses to
the Standard Library routines. Whatever the benefit (if any) of mandating a
particular behavior across implementations - is purchased at the vendors'
expense; the vendors would lose the latitude currently afforded them = they
would lose the freedom to exercise their own best judgment and to implement
whatever throw() behavior they deem best - both for themselves and for their
clients.
Greg
---
[ 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 ]