Re: How on earth did noexcept get through the standards process?
Am 09.04.2011 13:01, schrieb restor:
[..]
The case is different for destructors: you may wish to
annotate
your destructor as noexcept(false) if you do want it to throw.
Apart from that it will be only STD library authors that will declare
their functions with noexcept.
... which they usually don't need to do in an active form, because the
language assigns a default nothrow-exception-specification to all
destructors, unless base classes or member types don't object actively.
And it looks I was also incorrect about destructors too. I tried to
read through the latest standard draft and I found the following rule
for destructors
Before answering let me anticipate that there is one current defect in
the core wording, because it misses to clarify *which* form of the
nothrowing exception-specification (throw() or the equivalent of
noexcept(true)) will be applied. In my reply below I ignore this detail
and assume that it will be the equivalent of noexcept(true).
(correct me if I am wrong).
struct POD {
std::string name_;
~POD() { // (1) implicitly noexcept(true)
name_.clear();
}
};
Correct (The name POD here is a bit misleading here, because POD is not
a POD type).
During the Madrid meeting the following new library requirement has been
added:
"Every destructor in the C++ standard library shall behave as if it had
a non-throwing exception specification."
which allows this deduction from std::string.
struct LoggedA {
POD pod_;
~LoggedA() { //(2) implicitly noexcept(true)
LOG()<< pod_; // may throw
}
};
Correct.
struct LoggedB {
POD pod_;
~LoggedB() noexcept(false) { //(3)
LOG()<< pod_; // may throw
}
};
struct Big {
LoggedB logged_;
~Big() { // (4) IMPLICIT noexcept(false)
; // empty
}
};
Correct.
That is, as in (2) if all sub-objects have noexcept(true) destructors,
our destructor is by default also a noexcept(true) one even if we
throw
in the body. However, if we have a noexcept(false) sub-object, our
destructor is by default noexcept(false).
Yes, this is the mental model behind that (ignoring details about
dynamic-exception-specifications). For reference to others I provide
some relevant normative wording:
1) 12.4 [class.dtor] p. 3:
"A declaration of a destructor that does not have an
exception-specification is implicitly considered to have the same
exception-specification as an implicit declaration (15.4)."
This explains why in (2) the compiler is requested to ignore the content
of destructor body. It is supposed to look into 15.4 instead, which
follows below. Example (3) is the only case where a destructor has a
non-implicit exception-specification.
2) 15.4 [except.spec] p. 14:
"An implicitly declared special member function (Clause 12) shall have
an exception-specification. If f is an implicitly declared [..]
destructor, [..] its implicit exception-specification specifies the
type-id T if and only if T is allowed by the exception-specification of
a function directly invoked by f's implicit definition; f shall allow
all exceptions if any function it directly invokes allows all
exceptions, and f shall allow no exceptions if every function it
directly invokes allows no exceptions."
a) The first sentence makes clear, that *all* destructors have an
exception-specification.
b) The reference to
"a function directly invoked by f's implicit definition"
ensures that the compiler is supposed to look at the
exception-specifications of the destructors of the non-static members
and base classes solely (It is an indirect consequence of 15.4 again not
to look into the destructor body of any of these).
c) There are no non-empty dynamic-exception-specifications involved
here, so the sentence about "type-id T" is irrelevant here.
d) The part
"f shall allow all exceptions if any function it directly invokes allows
all exceptions"
has the effect that (4) has to add the exception-specification
noexcept(false) because it's member LoggedB has an
exception-specification that allows all exceptions.
In all other cases (and given the new library guarantee mentioned above)
we fall into the last part:
"f shall allow no exceptions if every function it directly invokes
allows no exceptions"
Again: These functions can *only* be destructors, never functions that
are called in some body of any of these destructors.
HTH & Greetings from Bremen,
Daniel Kr?gler
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]