C++ tidbit #8: Damaging Default Destructor

Special member functions are implicitly generated by the compiler if the user didn't provide them - constructors, destructors, assignments, and moves. Here, for example, a move ctor for C is used although it was never declared or defined in code:

struct C {
  std::string s;
};

void f() {
? ? C c1;
? ? c1.s = "asdf";
? ? C c2 = std::move(c1);  // <-- calls an auto-generated C(C&&)
}
        

Kinda-Reasonable, Part I

Auto generation of move ctors - as well as of some other special member functions - is dependent on the compiler being certain that it doesn't need to do anything fancy. This does not entail any real fancy-detection logic: per the standard, if the user has provided some (for example) copy ctor - copy operations aren't trivial and it would be a mistake to let the compiler implicitly generate move, that could be missing needed functionality. Similarly, if the code has a user-given dtor, something non-automatic probably needs to be done to the object that is the potential move target - and implicit generation of moves (ctor and assignment) is inhibited.

Note that 'user given' could mean an empty definition like `{}`- no analysis whatsoever is applied to the special members in question:

struct C  
 std::string s;
 ~C() {}   // Prevents implicitly generating C::C(C&&)
};

void f() {?
 ? C c1;?
 ? c1.s = "asdf";?
 ? C c2 = std::move(c1);  // <-- now calls C::C(C const&) 
}        

Let it be said already that this reasoning isn't entirely sound. The line `C c2 = ...` does not involve any destruction of previous `c2` contents, and one could imagine a C++ standard in which an auto-generated move would apply here.

Still-Mostly-Reasonable, Part II

`default constructor` was a very unfortunate historical choice of term for a ctor with no parameters. In C++11 true `defaults` joined in:

C() = default;
~C() = default;
C(C&) = default;
C(C&&) = default;
...        

In C++ jargon these are called 'defaulted' to distinguish them from 'default', and confusing idioms like 'defaulted default constructor' started to appear. The motivation for these was mostly to re-enable implicit special members that were inhibited by the logic in part I:

struct C {
? ? std::string s;
? ? ~C() {};          // <-- prevents implicit move ctor
? ? C(C&&) = default; // <-- restores move-ctor functionality
                      //     but inhibits default (=no-param) ctor 
? ? C() = default;    // <-- restores defaulted-default ctor
};


void f() {
? ? C c1;
? ? c1.s = "asdf";
? ? C c2 = std::move(c1);  <-- Huzzah! move is called again
}        

Another minor motivation for `=default` was to easily change the access specifier of a special member function without touching its implementation, and you sometimes see 'better code documentation' as an added value. Some good discussion is available in MS docs.

Utter Madness, Part III

Here's some more exact wording for the implicit-move inhibition rules, quoting cppreference:

" If no user-defined move assignment operators are provided ..., and all of the following is true:

• there are no user-declared copy constructors;
• there are no user-declared move constructors;
• there are no user-declared copy assignment operators;
• there is no user-declared destructor,

then the compiler will declare a move assignment operator... ."

This phrasing contains a small but potent landmine: user-declared.

Not provided, declared.

For reasons unbeknownst to me, `=default` counts as user-declared.

In this code, implicit move is inhibited:

struct C 
? ? std::string s;
? ? ~C() = default;  // <-- !
};


void f() {
? ? C c1;
? ? c1.s = "asdf";
? ? C c2 = std::move(c1);  // <-- no move.   !? 
}        

You might have reasonably assumed that spreading `=default`s around is at worst meaningless. It isn't - at worst it's a (potentially substantial) pessimization.

<sigh/>

There might be some real use cases lurking out of my sight where this is in fact the desired impact of `=default` (do tell me if you have one!) - but I suspect this is just another accidental side effect of the standard complexity. If this was really a design choice by the committee - it certainly brought about more confusion then benefit.