What is the purpose of adding a defininition for a pure-virtual destructor?

Question

Inspired by: C++ -- why should we define the pure virtual destructor outside the class definition?

What does the following code actually do?

class Object
{
    public:
    virtual ~Object() = 0;
};

Object::~Object() { /*...*/ }

I thought that the point of a pure virtual function was to force subclasses to implement that particular function. If that is the case, then why bother implementing the same function in the virtual base class?

[There's a GotW article specifically about the purpose of pure virtual functions with definitions.](http://www.gotw.ca/gotw/031.htm) — In silico, Mar 10 '11 at 17:48
I cannot comment on the pure virtual destructor, but in general the definition of pure virtual function provides *default* implementation, which the derived class may *explicitly* choose to execute! — Nawaz, Mar 10 '11 at 17:51
@Nawaz: That's _virtual functions_. I have rarely ever implemented a _pure_ virtual function, and certainly haven't done so in the last ten years. Except for pure virtual destructors, which always must be implemented. — sbi, Mar 10 '11 at 17:53
@sbi: I'm talking about *pure virtual function* which the derived can choose to run! — Nawaz, Mar 10 '11 at 17:55
@Nawaz: I consider calling base class virtuals when overriding them fishy anyway, even if not pure. Do you have to call it _before_ or _after_ your own implementation? Or in the middle? Or do you have to at all? I'm all in favor for [_never_](http://en.wikipedia.org/wiki/Template_method_pattern). That's dead easy. Given that, what's a use case for an _implemented_ pure virtual function? — sbi, Mar 10 '11 at 18:32
@sbi: Honestly, I never used *pure* virtual function with default implementation. So can't talk about any real use-case. But what I said is only from the theoretical point of view. And of course the design patters are more elegant than such language integrated approach or whatever you call it. — Nawaz, Mar 10 '11 at 18:37

score 10 · Accepted Answer · answered Mar 10 '11 at 17:47

10

This code prevents you from creating an instance of Object, while at the same time allowing you to create subclasses.

When destroying an object, the destructor of the parent class will be called, so it must exist. This applies whether the destructor is pure virtual or not. A pure virtual member function only needs to be defined if you explicitly call it, Foo:theFunc().

answered Mar 10 '11 at 17:47

Erik

88,732
13
198
189

Thanks, Erik. That makes a lot of sense. – e.James Mar 10 '11 at 17:59
Similar to making all constructors private then? – reuscam Mar 10 '11 at 20:22
1

A private constructor prevents you from inheriting, not from instantiating (from e.g. a static member) – Erik Mar 10 '11 at 20:39

score 2 · Answer 2 · answered Mar 10 '11 at 19:27

In the case of a pure virtual destructor, there is no way of 'forcing' anyone to implement it in derived classes. The compiler will write one for you. In addition, the compiler written destructor (in a derived class) will call the parent destructor - so you had better have written an implementation for the parent.

So, to summarise:

A pure virtual function that is not a destructor need not have an implementation as you would not expect a programmer to call it.
A pure virtual destructor must have an implementation since the compiler is bound to call it from destructors (both programmer and compiler written) in child classes.

What is the purpose of adding a defininition for a pure-virtual destructor?

2 Answers2