While going through the last edits of the C++0x Working draft I found a lot of
noexcept
and vice versa. Just some examples:
noexcept
against Throws: nothing: 20.6.4 Pointer safety [util.dynamic.safety] template<class T> T*undeclare_reachable(T*p);
noexcept
: 20.6.3.2. Pointer traits member functions [pointer.traits.functions]: static pointer pointer_trait<T*>::pointer_to(...) noexcept;
Questions here:
noexcept
vs. Throws: nothing in the Std-Lib?noexcept
to their own functions?If you throw, your program terminates What happens if you throw from a noexcept function? Your program terminates, and may or may not unwind the stack. Terminating program isn't the nicest way to report an error to your user. You would be surprised that most of C++ code might throw.
That noexcept keyword is tricky, but just know that if you use it, your coding world will spin faster.
The primary use of noexcept is for generic algorithms, e.g., when resizing a std::vector<T> : for an efficient algorithm moving elements it is necessary to know ahead of time that none of the moves will throw. If moving elements might throw, elements need to be copied instead.
The noexcept specifier with a Boolean parameter. The noexcept specifier has an optional Boolean parameter. noexcept(true) is equivalent to noexcept , meaning the function is non-throwing. noexcept(false) means the function is potentially throwing.
In Madrid we were strongly influenced by N3279 which includes the following guidelines:
Adopted Guidelines
No library destructor should throw. They shall use the implicitly supplied (non- throwing) exception specification.
Each library function having a wide contract, that the LWG agree cannot throw, should be marked as unconditionally noexcept.
If a library swap function, move-constructor, or move-assignment operator is conditionally-wide (i.e. can be proven to not throw by applying the noexcept operator) then it should be marked as conditionally noexcept. No other function should use a conditional noexcept specification.
Library functions designed for compatibility with “C” code (such as the atomics facility), may be marked as unconditionally noexcept.
I would not interpret these guidelines as necessarily targeting a wider audience. This is mainly an admission that we do have backward compatibility concerns with adding noexcept. If we get it wrong, noexcept is easier to add than to remove in the next standard. So we attempted an application of noexcept that was both conservative and systematic.
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