Rule of 3 Default Member Deprecation in C++11

Question

According to the below widely-known table, automatic compiler generation of default copy constructor and copy assignment is deprecated in C++11 when one or more of the copy assignment, copy constructor, and destructor is/are supplied by the user (the red cells indicate deprecation). This makes perfect sense in light of the "Rule of 3". However, the table shows that generation of the default destructor is not deprecated in the case of user-supplied copy constructor/assignment.

What is the rationale behind this design decision?

Reference Table

@Angew seems like I worded it backwards ;) thanks for the heads up, will edit — chili, Jun 08 '17 at 08:57
How could you not have a destructor? Something needs to deconstruct the member variables. — Galik, Jun 08 '17 at 09:04
@Galik It would just mean the dtor would have to be user-provided too. — Angew is no longer proud of SO, Jun 08 '17 at 09:07
@Angew Which would be weird. You always expect the member variables to construct and deconstruct without you having to explicitly add a constructor or destructor. So the only time the compiler doesn't create a constructor or destructor is when the user supplies one. — Galik, Jun 08 '17 at 09:12
I don't see the word "deprecated" in that table. Did I miss it, or are you using the wrong word? — Yakk - Adam Nevraumont, Jun 08 '17 at 14:09
@Yakk The table is part of a larger presentation in which the meaning of the red cells is given. — chili, Jun 09 '17 at 02:55

score 2 · Accepted Answer · edited Jun 08 '17 at 09:22

Why should it be deprecated? It's perfectly possible for an object to require special copying properties, but its for destruction to be fully determined by its sub-object destructors. Consider a simple cloning pointer:

template <class T>
class cloning_ptr
{
  std::unique_ptr<T> p;

public:
  cloning_ptr(const cloning_ptr &src) : p(std::make_unique<T>(*src.p) {}
  cloning_ptr(cloning_ptr &&) = default;

  cloning_ptr& operator= (cloning_ptr rhs)
  { swap(p, rhs.p); return *this; }    
};

There's zero reason to provide a destructor that does anything different from the defaulted one.

The other way around is different: if you need to do special things in a dtor, that probably means there is some non-standard ownership modeled in the class. Non-standard ownership will most likely need handling in copy operations, too.

Rule of 3 Default Member Deprecation in C++11

1 Answers1

Linked