Menu
I've heard that noexcept keyword is more like 'it should never throw an exception' rather than 'it doesn't'.
I don't think it's good to use noexcept keyword if I'm not sure it throws an exception or not, but noexcept keyword is sometimes related to the performance like in a move constructor.
So I tried to use noexcept qualifiers, but it gets harder if it has multiple statements in the definition and it becomes a kind of copy-and-paste thing.
template <class T>
void f(T&& t)
noexcept(noexcept(statement_1) &&
noexcept(statement_2) &&
noexcept(statement_3) &&
noexcept(statement_4) &&
noexcept(statement_5))
{
statement_1;
statement_2;
statement_3;
statement_4;
statement_5;
}
I think the compiler can figure out whether the definition of a function consists of non-throwing statements, so it will be easier to utilize noexcept if there's an expression like noexcept(auto), but it seems that there is no such thing in the standard.
Is there any way to simplify the noexcept expression?
600
The noexcept operator performs a compile-time check that returns true if an expression is declared to not throw any exceptions. It can be used within a function template's noexcept specifier to declare that the function will throw exceptions for some types but not others.
Explicit instantiations may use the noexcept specifier, but it is not required. If used, the exception specification must be the same as for all other declarations.
That noexcept keyword is tricky, but just know that if you use it, your coding world will spin faster.
In contrast, noexcept(false) means that the function may throw an exception. The noexcept specification is part of the function type but can not be used for function overloading. There are two good reasons for the use of noexcept: First, an exception specifier documents the behaviour of the function.
Currently there is none. There is, however, a proposal on that topic, which proposes noexcept(auto) syntax: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4473
The status of this proposal is "needs further work", according to Botond Ballo's "Trip Report: C++ Standards Meeting in Lenexa, May 2015" https://botondballo.wordpress.com/2015/06/05/trip-report-c-standards-meeting-in-lenexa-may-2015/
Further Work. The proposal’s direction is promising, but it is either not fleshed out well enough, or there are specific concerns with one or more design points. The author is encouraged to come back with a modified proposal that is more fleshed out and/or addresses the stated concerns.
...
noexcept(auto), which basically means “deduce the noexcept-ness of this function from the noexcept-ness of the functions it calls. Like return type deduction, this requires the body of the function being available in each translation unit that uses the function. It was brought up that, together with the proposal for making exception specifications part of the type system, this would mean that modifying the function’s body could change the function’s type (again similarly to return type deduction), but people weren’t overly concerned about that.
175
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
