C++ – What are the consequences of no virtual destructor for this base class

cvirtual-functions

I found this same code here:
https://stackoverflow.com/a/5854862/257299

struct Base { virtual Base& operator+=(int) = 0; };

struct X : Base
{
    X(int n) : n_(n) { }
    X& operator+=(int n) { n_ += n; return *this; }
    int n_;
};

struct Y : Base
{
    Y(double n) : n_(n) { }
    Y& operator+=(int n) { n_ += n; return *this; }
    double n_;
};

void f(Base& x) { x += 2; } // run-time polymorphic dispatch

I have read many Q&As about when (and when not) to use a virtual destructor, but I am stumped by this sample code. My textbook understanding of C++ says: "Aha! A base class without a virtual destructor is bad. Memory leak or undefined behaviour may occur." I also think this style appears in the C++ standard library, but I don't know an example off the top of my head.

What happens if I use X (and Y) as such…?

X* x = new X(5);
// Scenario 1
delete x;  // undefined behaviour...?  Does default dtor for `Base` get called?
// Scenario 2
Base* b = x;
delete x;  // undefined behaviour...?

Perhaps I am confused about (a) using a class safely without a virtual destructor versus (b) safety-by-design / I cannot get it wrong.

In case (a), to use safely, only stack allocate. This requires discipline!

In case (b), either add a virtual destructor in Base or force stack allocation via a private constructor and public static factory method. This does not require discipline. (Although this comment from David Rodríguez confused me more! "Why would you want to do this [prevent heap allocation]?")

Best Answer

In your first scenario, the behavior is defined. You have a pointer to X and you destroy an X via that pointer. The fact that X derived from B doesn't cause a problem.

The second scenario is where the big problem arises. Here you have undefined behavior, because you're destroying a derived object via a pointer to the base object. In such a case you must have a virtual dtor to get defined behavior.

The exact result of doing this varies. In some cases, the program can crash. In others, the base dtor is invoked but the derived dtor isn't, so the object is partially (but not completely) destroyed. I did give some concrete examples for one example, in an answer on SO. That's just one particular case though--changing the compiler or code could change the result completely.

At least in my opinion, attempting to eliminate dynamic allocation isn't really a cure. For example, consider code like this:

#include <iostream>

struct base {
    virtual void show() { std::cout << "type: base\n"; }
};


struct derived : public base {
    derived operator+(int) { return derived(); }
    virtual void show() { std::cout << "type: derived\n"; }
};

void f(derived &d) {
    base &bb{ d+1 };
    bb.show();
    // boom!
}

int main() {
    derived d;
    f(d);
}

When we invoke bb.show(), it (as expected) shows that the type is derived. That is, we have a reference to base bound to a temporary object of type derived. At the end of the function (marked "boom!") that temporary object of type derived is destroyed via a reference to base. We haven't used any dynamic (or static) allocation, but we still have undefined behavior.

This is probably why David Rodriguez (who's a smart guy and knows C++ well--continue paying attention to what he says) asked what he did--at least for the situation under discussion, preventing dynamic allocation doesn't prevent problems.

Related Solutions

C++ – Is it possible to refactor inheritance to composition when virtual methods are called inside the base class

So let's make this concrete-ish.

class Country {
  virtual void foo();
  void bar() {
    foo();
  }
}

Moving toward:

class Country {
  private thingWhichWasSubclass;
  void bar() {
    thingWhichWasSubclass.foo();
  }
}

Is that right? How about as an intermediate step:

class Country {
  private thingWhichWasSubclass;
  void foo() {
    thingWhichWasSubclass.foo();
  }
  void bar() {
    foo();
  }
}

Would that do it? Then (of course) inline Country.foo().

C++ Rule of Three – How to Setup the Rule of Three in a Virtual Base Class

The requirement looks wrong. The reason is that virtual methods and copy constructors don't work together. Virtual methods are useful if you use the object polymorphically, that is via reference/pointer to a base class. But copy constructor always constructs object of the static type it is written as, so if you give it polymorphic object, it will only create the base class, not the subclass you wanted. This is called slicing.

So you want to either:

Have a templated framework that knows the type at compile time and uses copy-constructor. But this does not need any virtual methods, nor for that matter a common base type, since the code will be compiled with the specific template parameter. Compiler will complain if the type substituted does not support the operations the template tries to use, but you can slightly improve diagnostics by using some explicit checks, e.g. from Boost.Concept Check.
Have a framework using polymorphic objects with base class, but that can't create copies with copy constructor, because it does not know the type to construct. There are three ways out:
1. Have a pure virtual Base *clone() method, that will be implemented to do return new Derived(this) in each concrete subclass. You should probably wrap that in unique_ptr or shared_ptr immediately to avoid leaking the copies.
2. Instead of copies, hand out references or smart pointers, probably shared_ptr in this case. It would probably be either const references/smart pointers or typed with interface that only contains methods that can't affect invariants in the framework.
3. Make the method that inserts the objects a template, that would construct a cloner and store it along with the object. Cloner is a function template<typename T> Base *clone(const Base *obj) { return new T(dynamic_cast<const T &>(*obj); } (you can have a functor or a class with multiple helper methods like this). To ensure you really have correct type, the insert method should probably wrap the call to new as well similar to e.g. make_shared.

By the way, nothing of this has anything to do with rule of three. Because rule of three says that if default copy constructor, default assignment operator or default destructor are not good enough for the class, than none of them is. But not because compiler would require it, but because the logic probably does. But for most classes that want to be copyable they are good enough. Because in most cases you hide the resource handling in some smart pointer and just let the default copy/assignment/destructor call to it.

Best Answer

Related Solutions

C++ – Is it possible to refactor inheritance to composition when virtual methods are called inside the base class

C++ Rule of Three – How to Setup the Rule of Three in a Virtual Base Class

Related Topic