Virtual destructor with virtual members in C++11

31
votes

In these slides about C++11/14 standard, on slide 15, the author writes that "many classic coding rules [are] no longer applicable" in C++11. He proposes a list of three examples, and I agree with the Rule of Three and the memory management.

However his second example is "Virtual destructor with virtual members" (just that). What does it mean? I know one must declare as virtual the base class destructor in order to call the right destructor if we have something like

Base *b = new Derived;
...
delete b;

This is well explained here: When to use virtual destructors?

But is it useless now in C++11 to declare virtual your destructor if you have virtual members?

4
c++c++11virtual-destructor
This is just a guess, but when using smart pointers, you can arrange things such that the right destructor gets called, even if the base destructor is not virtual. This happens out of the box with shared_ptr. – juanchopanza
The statements to the effect that the rule of three or the need for a virtual destructor are no longer necessary are simply false. None of the new features have changed anything in this regard. – James Kanze
@JamesKanze About the Rule of Three, the author could also mean that it is deprecated, since now it is the Rule of Four/Five. For the Rule of Zero, I truly believe it is useful, but under the condition that your classes use the RAII principle for all resources they own. – Florian Richoux
@FlorianRichoux Not really. Most classes won't need the extra complexity of supporting move. (And making a class which uses resources which must be freed work correctly usually need a lot more than what the usual RAII classes can do.) – James Kanze
@JamesKanze, you're missing the point. If all your non-trivial members have a correct destructor or are an RAII type with a suitable deleter (whether that just deletes memory or performs more complicated cleanup) then there is no extra complexity supporting move. You just say Foo(Foo&&) = default; and it Just Works™. And because all your members clean themselves up, you can also default the destructor. It requires a different approach to class design but that's the approach Prof. Sommerlad is advocating in those slides. (Not sure about the virtual bit though, I'll ask him.) – Jonathan Wakely

4 Answers

37
votes

As the author of the slides I'll try to clarify.

If you write code explicitly allocating a Derived instance with new and destroying it with delete using a base class pointer then you need to define a virtual destructor, otherwise you end up with incompletely destroying the Derived instance. However, I recommend to abstain from new and delete completely and use exclusively shared_ptr for referring to heap-allocated polymorphic objects, like

shared_ptr<Base> pb=make_shared<Derived>();

This way, the shared pointer keeps track of the original destructor to be used, even if shared_ptr<Base> is used to represent it. Once, the last referring shared_ptr goes out of scope or is reset, ~Derived() will be called and the memory released. Therefore, you don't need to make ~Base() virtual.

unique_ptr<Base> and make_unique<Derived> do not provide this feature, because they don't provide the mechanics of shared_ptr with respect to the deleter, because unique pointer is much simpler and aims for the lowest overhead and thus is not storing the extra function pointer needed for the deleter. With unique_ptr the deleter function is part of the type and thus a uniqe_ptr with a deleter referring to ~Derived would not be compatible with a unique_ptr<Base> using the default deleter, which would be wrong for a derived instance anyway, if ~Base wasn't virtual.

The individual suggestions I make, are meant to be easy to follow and followed all together. They try to produce simpler code, by letting all resource management be done by library components and the compiler generated code.

Defining a (virtual) destructor in a class, will prohibit a compiler-provided move constructor/assignment operator and might prohibit also a compiler provided copy constructor/assignment operator in future versions of C++. Resurrecting them has become easy with =default, but still looks like a lot of boilerplate code. And the best code is the code you don't have to write, because it can not be wrong (I know there are still exceptions to that rule).

To summarize "Don't define a (virtual) destructor" as a corollary to my "Rule of Zero":

Whenever you design a polymorphic (OO) class hierarchy in modern C++ and want/need to allocate its instances on the heap and access them through a base class pointer use make_shared<Derived>() to instantiate them and shared_ptr<Base> to keep them around. This allows you to keep the "Rule of Zero".

This doesn't mean you must allocate all polymorphic objects on the heap. For example, defining a function taking a (Base&) as parameter, can be called with a local Derived variable without problems and will behave polymorphic, with respect to virtual member functions of Base.

In my opinion dynamic OO polymorphism is heavily overused in many systems. We shouldn't program like Java, when we use C++, unless we have a problem, where dynamic polymorphism with heap allocated objects is the right solution.

2
votes

I think that this is to do with the "rule of zero" mentioned elsewhere in the presentation.

If you only have automatic member variables (i.e. use shared_ptr or unique_ptr for members that would otherwise be raw pointers) then you don't need to write your own copy or move constructors, or assignment operators -- the compiler-provided defaults will be optimal. With in-class initialisation, you don't need a default constructor either. And finally, you don't need to write a destructor at all, virtual or not.

0
votes

The paper linked shows the relevant code:

std::unique_ptr<Derived> { new Derived };

The stored deleter is std::default_delete<Derived>, which doesn't require Base::~Base to be virtual.

Now you can move this to a unique_ptr<Base>, and it will also move the std::default_delete<Derived> without converting it to a std::default_delete<Base>.

0
votes

To answer the specific question...

But is it useless now in C++11 to declare virtual your destructor if you have virtual members?

The need for a virtual destructor has NOT changed in the C++11 core language. You must declare your destructor as virtual if you are deleting the derived object using the base pointer.

The statement in the slide gives the impression that somehow C++11 has changed the behavior with respect to virtual destructor - which is not the case. As the author has clarified, it's only applicable when using a shared_ptr. But the fact that a virtual destructor is still required (except with the use shared_ptr) gets diluted in the long explanation.