6

What is the rationale behind the C++ Standard Committee choice of deleting the implicitly defined move assignment operator when a customized destructor is defined?

nyarlathotep108
  • 5,275
  • 2
  • 26
  • 64
  • i dont know so i can only guess: it might came from the `rule of 3` where when you need a destructor, you also need a copy and assignment operator. this could apply to the move operator as well – Zaiborg Dec 02 '15 at 12:11
  • Also see: http://stackoverflow.com/a/11255258/576911 – Howard Hinnant Dec 02 '15 at 16:28

2 Answers2

5

From Scott Meyer's Effective Modern C++ Item 17 (assuming you have knowledge of the Rule of Three):

A consequence of the Rule of Three is that the presence of a user-declared destructor indicates that simple memberwise copy is unlikely to be appropriate for the copying operations in the class. That, in turn, suggests that if a class declares a destructor, the copy operations probably shouldn't be automatically generated, because they wouldn't do the right thing. [...]

The reasoning behind the Rule of Three remains valid, however and that, combined with the observation that declaration of a copy operation precludes the implicit generation of the move operations, motivates the fact that C++11 does not generate move operations for a class with a user-declared destructor.

Community
  • 1
  • 1
TartanLlama
  • 63,752
  • 13
  • 157
  • 193
  • The rule of the three are only a set of suggestions, not actions from the compiler. As your post quotes: "if a class declares a destructor, the copy operations probably shouldn't be automatically generated". Why it has become a "must not be automatically generated" for the move operations? – nyarlathotep108 Dec 02 '15 at 13:07
  • 1
    @nyarlathotep108 The prospective problem is an incorrect implicit copy/move constructor when one isn't wanted. The committee made a decision to protect the user from this prospective problem by disabling the generation it this case. – TartanLlama Dec 02 '15 at 13:34
5

The idea is that the presence of any of the default-generated structors (copy constructor, copy assignment, or destructor) indicates that a type needs to do some sort of special resource management. If that is the case, the default move operations may not do the Right Thing. I'm not sure if actually failing examples where the default generated copy constructor works correctly but the default generated move constructor failed were presented.

The resolution was that it is safer to not generate the move operations by default, especially as it is easy to ask for the respective move operations: simply add a = defaulted implementation. The class clearly already does something special (otherwise there would be no destructor) anyway.

Dietmar Kühl
  • 150,225
  • 13
  • 225
  • 380
  • Why is it so for the move assignment operator and not for the copy assignment operator? – nyarlathotep108 Dec 02 '15 at 12:31
  • @nyarlathotep108: Historic ballast. The defaulted copy assignment is deprecated. – Kerrek SB Dec 02 '15 at 12:37
  • 1
    @nyarlathotep108: when the rules for copy construction were defined, there was no such thing as `= default`. Actually, people hadn't even figured out the [Rule of Three](https://en.wikipedia.org/wiki/Rule_of_three_(C%2B%2B_programming)) (which is actually incorrect: for Strong Exception safety it is sometimes necessary to implement the assignment operator although none of the other structors is needed). Changing the rules now would break a lot of code. That is, the short answer is as KerrekSB stated: "historic ballast" – Dietmar Kühl Dec 02 '15 at 13:57
  • @nyarlathotep108: The current standard actually deprecates automatic creation of the copy structors if any of the others is available (see D.3 [depr.impldec]). – Dietmar Kühl Dec 02 '15 at 13:59