Page History

The C++ Standard, [expr.delete], paragraph 3 [ISO/IEC 14882-2014], states the following:

In the first alternative (delete object), if the static type of the object to be deleted is different from its dynamic type, the static type shall be a base class of the dynamic type of the object to be deleted and the static type shall have a virtual destructor or the behavior is undefined. In the second alternative (delete array) if the dynamic type of the object to be deleted differs from its static type, the behavior is undefined.

Do not delete an object of derived class type through a pointer to its base class type that has a non-virtual destructor. Instead, the base class should be defined with a virtual destructor. Deleting an object through a pointer to a type without a virtual destructor results in undefined behavior.

Noncompliant Code Example

In this noncompliant example, b is a polymorphic pointer type whose static type is Base * and whose dynamic type is Derived *. When b is deleted, it results in undefined behavior because Base does not have a virtual destructor. The C++ Standard, [class.dtor], paragraph 4 [ISO/IEC 14882-2014], states the following:

If a class has no user-declared destructor, a destructor is implicitly declared as defaulted. An implicitly declared destructor is an inline public member of its class.

The implicitly declared destructor is not declared as virtual even in the presence of other virtual functions

Calling the destructor of a derived class in an inheritance hierarchy should invoke the destructors that class and all of its base classes. However, if the derived class is referenced by a pointer of a type higher up the class hierarchy, then the destructor of the pointer's type will be called rather than the destructor of the class being pointing to. Failure to declare a destructor as virtual may cause the wrong destructor to be called to destroy an object in an inheritance hierarchy.

Non-Compliant Code Example

In this non-compliant example, a reference to the parent class Base is used to instantiate a Derived object. When b is deleted, the destructor for Base is invoked rather than the destructor for Derived. As a result, the object b refers to will be improperly destroyed.

struct
class Base {
public:
  virtual void Basef() {
      // Build Base object
   }
   ~Base() {
      // Destroy Base object
   }
};

class Derived : public Base {
public:
   Derived;
};
 
struct Derived : Base {};
 
void f() {
  Base *b = new Derived();
  // ...
  delete b;
}

Noncompliant Code Example

In this noncompliant example, the explicit pointer operations have been replaced with a smart pointer object, demonstrating that smart pointers suffer from the same problem as other pointers. Because the default deleter for std::unique_ptr calls delete on the internal pointer value, the resulting behavior is identical to the previous noncompliant example.

#include <memory>
 
struct Base {
  virtual void f();
};
 
struct Derived : Base {};
 
void f() {
  std::unique_ptr<Base> b = std::make_unique<Derived>();
}

Compliant Solution

In this compliant solution, the destructor for Base has an explicitly declared virtual destructor, ensuring that the polymorphic delete operation results in well-defined behavior.

struct Base {
  virtual ~Base() = default;
  virtual void f();
};

struct Derived : Base {}  // Build Derived object
   }
   ~Derived() {
      // Destroy Derived object
   }
};

void functionf(void) {
   Base *b = new Derived();
   // ...
   delete b;
}

Compliant Solution

Exceptions

OOP52-CPP:EX0: Deleting a polymorphic object without a virtual destructor is permitted if the object is referenced by a pointer to its class, rather than via a pointer to a class it inherits fromTo correct this example, the destructor for Base should be declared virtual. This ensures that the object b refers to will be correctly evaluated at runtime thus, deleting b will call the destructor for class Derived.

class Base {
public:
  // ...
  virtual void AddRef() = 0;
  virtual void Destroy() = 0;
};

class Derived final : public Base {
public:
  // ...
  virtual void AddRef() { /* ... */ }
  virtual void Destroy() { delete this; }
private:
  ~Derived() {}
};

Note that if Derived were not marked as final, then delete this could actually reference a subclass of Derived, violating this rule.

OOP52-CPP:EX1: Deleting a polymorphic object without a virtual destructor is permitted if its base class has a destroying operator delete that will figure out the correct derived class's destructor to call by other means.

#include <new>

class Base {
  const int whichDerived;

protected:
  Base(int whichDerived) : whichDerived(whichDerived) {}

public:
  Base() : Base(0) {}
  void operator delete(Base *, std::destroying_delete_t);
};

struct Derived1 final : Base {
  Derived1() : Base(1) {}
};

struct Derived2 final : Base {
  Derived2() : Base(2) {}
};

void Base::operator delete(Base *b, std::destroying_delete_t) {
  switch (b->whichDerived) {
  case 0:
    b->~Base();
    break;
  case 1:
    static_cast<Derived1 *>(b)->~Derived1();
    break;
  case 2:
    static_cast<Derived2 *>(b)->~Derived2();
  }
  ::operator delete(b);
}

void f() {
   Base() {
      // Build Base object
   }
   virtual ~Base() {
      // Destroy Base object
   }
};

class Derived : public Base {
public:
   Derived() {
      // Build Derived object
   }
   ~Derived() {
      // Destroy Derived object
   }
};

void function(void) {
   Base *b = new DerivedDerived1();
   // ...
   delete b;
}

Risk Assessment

Calling the wrong destructor may lead to resource mismanagement and possibly unintended program behavior.Attempting to destruct a polymorphic object that does not have a virtual destructor declared results in undefined behavior. In practice, potential consequences include abnormal program termination and memory leaks. 

...

Automated Detection

Related Vulnerabilities

Search for other vulnerabilities resulting from the violation of this rule on the CERT website.

Related Guidelines

Bibliography

...

Image Added Image Added Image Added