Re: How on earth did noexcept get through the standards process?
On 2011-03-30 03:41, DeMarcus wrote:
On 03/29/2011 01:29 AM, Daniel Kr?gler wrote:
On 2011-03-21 13:45, DeMarcus wrote:
Correct me if I'm wrong, but isn't there one more difference; unlike
throw(), noexcept is checked in compile-time so I get a warning or error
if a noexcept function throws?
In either case the compiler might give a warning, because it is allowed
;-) Seriously, since both behaviours are runtime-defined ending up in
very similar effects, I see no reason, why a compiler should warn
differently in either
void foo() throw() {
throw 42;
}
compared to
void foo() noexcept {
throw 42;
}
I thought we would have compile-time checks for noexcept, giving us a
compiler error in your last example.
A compiler is *required* to accept this program, see 15.4 p. 11 in N3242:
"An implementation shall not reject an expression merely because when executed it throws or might throw an exception that the containing function does not allow."
I looked into N2855. (If there's a better paper on noexcept, please tell
me)
This was one of the first proposal papers, but is very different from what finally became accepted. See
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3050.html
for the finally accepted paper.
http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2009/n2855.html#noexcept-block
In N2855 they would have solved your last example like this.
void foo() noexcept {
noexcept { throw 42; }
}
Then we can let the compiler do compile-time checks as well as having
run-time checks where the user wants.
Why can't we have the compile-time checks?
You can ask for them in the future (with new syntax), but there was no consensus to make this change now. Note that the above noexcept syntax does not cover constructor initializer lists, which is a real problem. You can use the noexcept operator to check whether an expression might throw an exception. This feature has been applied to the Standard Library to auto-deduce the effective noexcept-specification especially of special move members and of swap functions, because it solved the problem how containers can work with potentially throwing move operations. Arguably, the syntax is a bit awkward (using noexcept twice) and I believe that in the future we want syntactically simplified forms of this, like noexcept(auto) as described in
http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3207.htm
or some such. For a bit more about the rationale for the decisions regarding noexcept and C++0x see e.g.
http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3202.pdf
The fact that even after the current noexcept specification in the current working paper considerable improvement suggestions have been made, e.g. in
http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3227.html
implies to me that noexcept might undergo further (backward-compatible) changes and extensions in the future. IMO this is a good thing.
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! ]