Re: How on earth did noexcept get through the standards process?
On 30/03/2011 23:36, DeMarcus wrote:
On 03/30/2011 03:51 AM, CornedBee wrote:
On Mar 29, 1:29 am, Daniel Kr=FCgler<daniel.krueg...@googlemail.com>
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 ;-)
But you won't get an error. In fact, the standard explicitly forbids
the compiler from failing compilation:
[except.spec]p11: "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 tried the newly released g++ 4.6.0 yesterday and compiled below code.
void fnc() noexcept
{
throw 42;
}
I did not even get a warning. What a disappointment!
It seems I have a lot to learn about noexcept. I would appreciate if
someone could explain why the compiler doesn't give me an error on above
code, and also why the N2855 paper's noexcept block (see below) is not
part of C++0x anymore.
I think the first thing to recognise is that after a dozen years exception
specifications in C++ are clearly a failure. The only residual part that
seems potentially useful is throw() (i.e. throws nothing). It would be nice
if that could be statically (i.e. at compile time) checked.
I believe that the motivation behind 'noexcept' was to pull the
functionality of throw() out of exception specifications so that:
1) We can provide more detailed requirements for that case without having t=
o
add verbiage to everywhere that throw specifications are mentioned.
2) Allow the eventual removal of throw specifications (rather like the
human appendix, they do not appear to have any beneficial purpose, but are
only a source of potential problems.
Ideally we would like noexcept to be statically checked. Unfortunately that
would break reams of existing code and seriously inhibit the uptake of
noexcept.
However if the body of a noexcept qualified function does not call
unqualified (i.e. noexcept(false) ) functions and does not itself throw
directly then it becomes possible to optimise its implementation by removin=
g
checks for exceptions and preparation for handling exceptions. (note that
that has implications wrt stack unwinding as the function will no longer be
able to allow an exception to pass through it)
In addition the standard can specify the exception default behaviour for
such things as dtors (as long as it provides a mechanism to allow the
default behaviour to be overruled)
Now the fact that an implementation fails to warn about a manifest breach o=
f
a noexcept qualification is disappointing and I hope that this will soon be
rare. In addition it would be helpful if implementations issued warnings
when they cannot enforce noexcept statically.
I am saddened by the number of people who seem to view noexcept entirely
negatively. Perhaps WG21 is being over-optimistic but it does seem to have
isolated the only place where exception specifications are potentially
useful and provided a mechanism by which this utility can be developed and
encouraged.
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]