Why do we need a pure virtual destructor in C++?

Question

I understand the need for a virtual destructor. But why do we need a pure virtual destructor? In one of the C++ articles, the author has mentioned that we use pure virtual destructor when we want to make a class abstract.

But we can make a class abstract by making any of the member functions as pure virtual.

So my questions are

1. When do we really make a destructor pure virtual? Can anybody give a good real time example?

2. When we are creating abstract classes is it a good practice to make the destructor also pure virtual? If yes..then why?

Answer 1

1. Probably the real reason that pure virtual destructors are allowed is that to prohibit them would mean adding another rule to the language and there's no need for this rule since no ill-effects can come from allowing a pure virtual destructor.

2. Nope, plain old virtual is enough.

If you create an object with default implementations for its virtual methods and want to make it abstract without forcing anyone to override any specific method, you can make the destructor pure virtual. I don't see much point in it but it's possible.

Note that since the compiler will generate an implicit destructor for derived classes, if the class's author does not do so, any derived classes will not be abstract. Therefore having the pure virtual destructor in the base class will not make any difference for the derived classes. It will only make the base class abstract (thanks for @kappa's comment).

One may also assume that every deriving class would probably need to have specific clean-up code and use the pure virtual destructor as a reminder to write one but this seems contrived (and unenforced).

Note: The destructor is the only method that even if it is pure virtual has to have an implementation in order to instantiate derived classes (yes pure virtual functions can have implementations).

struct foo {
    virtual void bar() = 0;
};

void foo::bar() { /* default implementation */ }

class foof : public foo {
    void bar() { foo::bar(); } // have to explicitly call default implementation.
};

Answer 2

This is a decade old topic :) Read last 5 paragraphs of Item #7 on "Effective C++" book for details, starts from "Occasionally it can be convenient to give a class a pure virtual destructor...."

Answer 3

Here I want to tell when we need virtual destructor and when we need pure virtual destructor

class Base
{
public:
    Base();
    virtual ~Base() = 0; // Pure virtual, now no one can create the Base Object directly 
};

Base::Base() { cout << "Base Constructor" << endl; }
Base::~Base() { cout << "Base Destructor" << endl; }


class Derived : public Base
{
public:
    Derived();
    ~Derived();
};

Derived::Derived() { cout << "Derived Constructor" << endl; }
Derived::~Derived() {   cout << "Derived Destructor" << endl; }


int _tmain(int argc, _TCHAR* argv[])
{
    Base* pBase = new Derived();
    delete pBase;

    Base* pBase2 = new Base(); // Error 1   error C2259: 'Base' : cannot instantiate abstract class
}

1. When you want that no one should be able to create the object of Base class directly, use pure virtual destructor virtual ~Base() = 0. Usually at-least one pure virtual function is required, let's take virtual ~Base() = 0, as this function.

2. When you do not need above thing, only you need the safe destruction of Derived class object

   Base* pBase = new Derived(); delete pBase; pure virtual destructor is not required, only virtual destructor will do the job.

Answer 4

You are getting into hypotheticals with these answers, so I will try to make a simpler, more down to earth explanation for clarity's sake.

The basic relationships of object oriented design are two: IS-A and HAS-A. I did not make those up. That is what they are called.

IS-A indicates that a particular object identifies as being of the class that is above it in a class hierarchy. A banana object is a fruit object if it is a subclass of the fruit class. This means that anywhere a fruit class can be used, a banana can be used. It is not reflexive , though. You can not substitute a base class for a specific class if that specific class is called for.

Has-a indicated that an object is part of a composite class and that there is an ownership relationship. It means in C++ that it is a member object and as such the onus is on the owning class to dispose of it or hand ownership off before destructing itself.

These two concepts are easier to realize in single-inheritance languages than in a multiple inheritance model like c++, but the rules are essentially the same. The complication comes when the class identity is ambiguous, such as passing a Banana class pointer into a function that takes a Fruit class pointer.

Virtual functions are, firstly, a run-time thing. It is part of polymorphism in that it is used to decide which function to run at the time it is called in the running program.

The virtual keyword is a compiler directive to bind functions in a certain order if there is ambiguity about the class identity. Virtual functions are always in parent classes (as far as I know) and indicate to the compiler that binding of member functions to their names should take place with the subclass function first and the parent class function after.

A Fruit class could have a virtual function color() that returns "NONE" by default. The Banana class color() function returns "YELLOW" or "BROWN".

But if the function taking a Fruit pointer calls color() on the Banana class sent to it -- which color() function gets invoked? The function would normally call Fruit::color() for a Fruit object.

That would 99% of the time not be what was intended. But if Fruit::color() was declared virtual then Banana:color() would be called for the object because the correct color() function would be bound to the Fruit pointer at the time of the call. The runtime will check what object the pointer points to because it was marked virtual in the Fruit class definition.

This is different than overriding a function in a subclass. In that case the Fruit pointer will call Fruit::color() if all it knows is that it IS-A pointer to Fruit.

So now to the idea of a "pure virtual function" comes up. It is a rather unfortunate phrase as purity has nothing to do with it. It means that it is intended that the base class method is never to be called. Indeed a pure virtual function can not be called. It must still be defined, however. A function signature must exist. Many coders make an empty implementation {} for completeness, but the compiler will generate one internally if not. In that case when the function is called even if the pointer is to Fruit , Banana::color() will be called as it is the only implementation of color() there is.

Now the final piece of the puzzle: constructors and destructors.

Pure virtual constructors are illegal, completely. That is just out.

But pure virtual destructors do work in the case that you want to forbid the creation of a base class instance. Only sub classes can be instantiated if the destructor of the base class is pure virtual. the convention is to assign it to 0.

 virtual ~Fruit() = 0;  // pure virtual 
 Fruit::~Fruit(){}      // destructor implementation

You do have to create an implementation in this case. The compiler knows this is what you are doing and makes sure you do it right, or it complains mightily that it can not link to all the functions it needs to compile. The errors can be confusing if you are not on the right track as to how you are modeling your class hierarchy.

So you are forbidden in this case to create instances of Fruit, but allowed to create instances of Banana.

A call to delete of the Fruit pointer that points to an instance of Banana will call Banana::~Banana() first and then call Fuit::~Fruit(), always. Because no matter what, when you call a subclass destructor, the base class destructor must follow.

Is it a bad model? It is more complicated in the design phase, yes, but it can ensure that correct linking is performed at run-time and that a subclass function is performed where there is ambiguity as to exactly which subclass is being accessed.

If you write C++ so that you only pass around exact class pointers with no generic nor ambiguous pointers, then virtual functions are not really needed. But if you require run-time flexibility of types (as in Apple Banana Orange ==> Fruit ) functions become easier and more versatile with less redundant code. You no longer have to write a function for each type of fruit, and you know that every fruit will respond to color() with its own correct function.

I hope this long-winded explanation solidifies the concept rather than confuses things. There are a lot of good examples out there to look at, and look at enough and actually run them and mess with them and you will get it.

Answer 5

we need to make destructor virtual bacause of the fact that , if we dont make the destructor virtual then compiler will only destruct the contents of base class , n all the derived classes will remain un changed , bacuse compiler will not call the destructor of any other class except the base class.

Answer 6

If you want to stop instantiating of base class without making any change in your already implemented and tested derive class, you implement a pure virtual destructor in your base class.