19

The move assignment operator should often be declared noexcept (i.e. to store the type in STL containers). But the copy-and-swap idiom allows both copy- and move- assignment operators to be defined in a single piece of code. What to do with noexcept specifier in this case? The copy construction can throw, but I doubt whether it can violate the noexcept specifier.

// Is it correct considering that T copy constructor can throw?
T& operator=(T other) noexcept;
lizarisk
  • 7,562
  • 10
  • 46
  • 70
  • 2
    The `noexcept` here is fine. Note that the `is_nothrow_*_constructible` traits will still return the correct value because they're implemented similar to `noexcept(declval() = declval())` which also takes into account whether the copy or move constructor throws (because that copy/move needs to happen to pass by value). – Simple Sep 17 '13 at 11:43
  • You may also be interested in: http://stackoverflow.com/a/7458222/576911 and http://stackoverflow.com/a/18303787/576911 – Howard Hinnant Sep 17 '13 at 15:11

2 Answers2

13

Since the copy is made on the caller's side of the call, it is not part of what your function does. It can therefore not be controlled by your function and consequently, you can not include this information in the noexcept specification.

The only thing you could do is to play it safe and add both options to your noexcept specification. Of course, that means you are getting some false-negatives.

Daniel Frey
  • 55,810
  • 13
  • 122
  • 180
  • Do you mean that exception thrown in copy constructor while passing py value to a function is not a part of this function, so it can be safely declared as noexcept? – lizarisk Sep 17 '13 at 11:33
  • @lizarisk "Safely" is a strong word. Basically, I'd say yes to that. The problem is that the **caller** must be aware of what it requires for his own `noexcept` specification. But then, from your perspective it's a SEP (somebody else's problem). – Daniel Frey Sep 17 '13 at 11:36
  • I'd answer that with "yes it is safe" as in "is correct" IFF the body does indeed not throw (which is the case for a swap). Example code proving this: https://godbolt.org/z/bzLOGA. Note how the traits `is_nothrow_*` still return the correct values. – Flamefire Jul 30 '19 at 14:01
10

As usual, Daniel Frey is correct. All I want is showing a piece of code that illustrates the point.

#include <iostream>

struct foo {

    foo() = default;

    foo(const foo&) {
        std::cout << "throw\n";
        throw 1;
    }

    foo& operator =(foo) noexcept {
        return *this;
    }
};

int main() {

    foo f, g;
    try {
        f = g; // throws
    }
    catch(int) {
        std::cout << "catch\n";
    }
}

When compiled with gcc 4.8.1 (-std=c++11 -Wall -Wextra -pedantic) it gives no warnings. Running the code produces the following output:

throw
catch

Therefore, the copy constructor does throw when called but that's no considered inside operator =() and, therefore, the noexcept promise was fulfilled. Otherwise, terminate would be called before catch could be printed out.

Community
  • 1
  • 1
Cassio Neri
  • 19,583
  • 7
  • 46
  • 68