Re: Is exception-safety possible at all?
Adam Badura wrote:
Just to make it clear. When I am writing about exception safety I mean
(unless otherwise written) strong exception safety. (The "succeed or
no [observable] effect".) But for most of the time it does not matter
much.
If you read a few sections back, you will see that having only a few
functions with a "Throws:" description is a good thing: In 17.3.1.3/3
we find
"Descriptions of function semantics contain the following elements
(as appropriate):148) [...]
- Throws: any exceptions thrown by the function, and the conditions
that would cause the exception [...]"
With footnote 148: "To save space, items that do not apply to a
function are omitted. For example, if a function does not specify any
further preconditions, there will be no "Requires" paragraph."
This tells us that, if there is no "Throws:" paragraph for a
function, the set of exceptions that might be thrown by that function
itself is empty. Thus, the function itself won't throw anything, but
it might still propagate an exception that was thrown by another
function that it needed to call to fulfil its requirements.
For example, std::vector::insert() does not have a Throws
description, but it may need to allocate more space and it needs to
call at least one constructor. Both of these may throw an exception
and that exception will be propagated by std::vector::insert().
That would be enough if the Standard specified details like that. But
it does not. What are guarantees that implementation will not call
allocator (and possibly fail in result) in "empty()"? Yes. It is a bit
extreme example. But it makes explanation much shorter then finding a
more reasonable but lengthy example.
In the same vein, where does the standard guarantee that a C++ compiler
is actually able to translate any C++ program?
The answer is that the standard doesn't, so it all comes down to QoI.
The standard does indeed not explicitly state that these operations
don't throw, but on the other hand, as long as you don't go into the
land of UB, all these operations are required you yield a result that
can't be deviated from and the standard does not include throwing an
exception as one of the possible results.
Division by 0 might result in an exception, but is is classified as
UB, so it might just as well result in a crash. The same for signed
overflow/underflow (unsigned overflow/underflow is defined as a
wrap-around operation, so no exception possible).
Choosing division by 0 as an example was a mistake. I just wanted to
have an obvious error. But the Standard (at least as I understand it)
makes no guarantee that following operation:
int a = 2;
will not throw. It might. As well as "2 + 3" or "a == 0".
Let's put those together in a program:
#include <stdio.h>
int main()
{
int a = 2;
if (a == 0)
{
printf("a == 0");
}
else
{
printf(" a == %d and 2+3 = %d\n", a, 2 + 3);
}
return 0;
}
As this program does not violate any rules of the C++ standard, clause
1.4/2 requires that when this program is passed to a conforming hosted
implementation, that implementation must provide (within its resource
limits) an executable that, when executed, prints the line
a == 2 and 2+3 = 6
and then signals successful termination to the OS.
An exception may only be thrown if this does not affect the observable
behaviour of this program.
If your portability requirements include support for the DS9000, then
you will have a hard time writing anything useful at all, exception
safe or not.
If you exclude insane systems, then it is certainly possible to write
portable, useful, exception safe code, but it does take a certain
amount of diligence.
I agree that implementation which throws from "empty" is not sane. But
still from how I understand the Standard for virtually all useful
pieces of code I could give an example of implementation valid by the
means of Standard in which the code is not exception-safe (in the
strong meaning of this term).
Yes. This would probably be a conforming implementation of std::swap:
namespace std {
template <class T> void swap(T& a, T& b)
{
char* temp = new[static_cast<size_t>(-1)];
T* t = new(temp) T();
*t = a;
a = b;
b = *t;
t->~T();
delete temp;
}
}
If you want to cater for such monstrosities, you are probably right that
it is not possible to write exception safe code in C++ (regardless of
the strength of safety that you take as a basis). But the, I doubt that
there is a definition of any language with exceptions that actively
forbids such perverse implementations that throw unspecified exceptions
for no particular reason.
Adam Badura
Bart v Ingen Schenau
--
a.c.l.l.c-c++ FAQ: http://www.comeaucomputing.com/learn/faq
c.l.c FAQ: http://c-faq.com/
c.l.c++ FAQ: http://www.parashift.com/c++-faq-lite/
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]