Should I use throw () when implementing a non-throwing exchange?

Question

When implementing non-flashing swap, should I use throw() ?

 namespace A { struct B { void swap( B& other ) throw() { /* fancy stuff that doesn't throw */ } }; void swap( B& lhs, B& rhs ) throw() { lhs.swap(rhs); } } namespace std { template<> void swap( A::B& lhs, A::B& rhs ) throw() { lhs.swap(rhs); } } 

In particular, I am worried about putting the throw() specification on the std::swap specialization.

Bonus question:
Is the answer different when using the C ++ 0x noexcept ?

Answer 1

In C ++ 03, you can put it there, but if it is true that fancy things don't throw, it is basically just documentation. This may or may not affect performance by adding the equivalent of try / catch(...) { std::unexpected(); } try / catch(...) { std::unexpected(); } around function calls: before implementation, whether it can do this without affecting performance.

If you plan to use the noexcept (5.3.7) operator in C ++ 0x, then suddenly it becomes advisable to have exception specifications without throwing, so that the operator gives a “correct” answer. I really don’t know what the noexcept operator is noexcept , but if there is a clever general use for it, for example, algorithms that become more efficient when something doesn't throw, then I think it will become necessary to mark the functions as not to throw, so that get the benefit.

For example:

 void foo() noexcept; void bar(); template <void(*FUNC)()> void generic_thing() { if (noexcept(FUNC()) { // this won't throw, perhaps we can somehow take advantage of that FUNC(); } else { // this might throw FUNC(); } } 

Old-style style exception specifications (dynamic exception specification) are deprecated in C ++ 0x (and pointless in C ++ 03).

Answer 2

This is not a good idea, no. The reason is that the standard knows that sometimes it is impossible to ensure the correctness of throw() , for which throw() was first introduced. In particular, in the case of patterns where an exception may or may not be selected depending on the instance, it is not possible to verify the correctness without creating a pattern. Therefore, the standard does not require compilers to enforce an exception specifier; in fact, it prohibits the implementation from rejecting the expression “simply because, when executed, it throws or can throw an exception that the containing function does not allow” (15.4 / 11).

If throw() has no effect other than documentation, it should be commented out; thus, at least, this does not constitute a danger to mislead the human observer.

The case with noexcept completely different. noexcept occurs for another reason; that performance. If you can guarantee that the compiler does not throw any exceptions, the compiler allows itself to perform some optimizations. But you will have to do the checks yourself. So, if swap() really doesn't throw out (and it shouldn't be that its raison d'être), then specifying noexcept is a good idea.

Answer 3

Really, no. Exceptional features were a great idea, but their reality was that they interfered more than most of the code helped. No one uses them, and they are deprecated in C ++ 0x. Don't waste your time creating exception specifications in modern C ++.