TITLE: why pure virtual destructors


DB  = davidb@datalytics.com (David Bradley)
RMC = rmartin@rcmcon.com (Robert Martin), 4 Oct 95
SC  = clamage@Eng.Sun.COM (Steve Clamage), 3 Oct 95


DB:

This issue came up recently.  I was wondering what the concensus is
about pure virtual destructors?  My compiler seems to accept them.
But I find nothing in the ARM about them.  Basically I have an
abstract base class that doesn't have any data and doesn't need to
destroy anything.  I don't necessarily know if the derived classes
will need a destructor or not.

The advantage is it saves space used by the stub code of the
destructor.

RMC:

No!  The destructor must be implemented.  If you don't implement it,
you will probably get a link error.  Remember, when an object is
destroyed, all the destructors for all its base classes are called,
even if they are pure.  This is the one and only case where a pure
virtual function must be implemented.

DB:

The possible disadvantage is that it requires all derived classes to
provide a destructor whether they need to or not.

RMC:

No!  Destructors are not inherited.  Thus, derived classes do not need
to specify a destructor.  As always, one will be provided for them if
not explicitly declared.


So what do pure virtual destructors do?  Their one and only function
is to make the class that contains them abstract.  You cannot
instantiate a class that has a pure virtual destructor.  So, if you
have a class that you think ought to be abstract, and none of its
virtual functions are pure (perhaps because you want to specify some
defaults) then make the destructor pure.

SC:

A class needs a destructor if any of its base classes or members has or
needs a destructor (and so on recursively).

If a class needs a destructor, it has one whether you declare it or not;
the compiler must generate it for you if you do not declare one. If you
do declare one, you must provide the body.

When an object's destructor is invoked, the base-class destructors are
invoked automatically. You cannot affect that behavior; it always happens.
(You could exit a destructor via an exception, but that's a special case.)

If a class is intended to be derived from, it should have a virtual
destructor. You can make the destructor pure virtual, but if you do, you
must still provide a body for the destructor. When any derived class object
is destroyed, that pure virtual destructor will be called automatically.
(If you don't provide the body, your program will probably fail to link.)

If a class has any pure virtual functions, you cannot create objects of
that type. Such a class is usually called "abstract", since its primary
purpose is to define an interface. If for some reason you want a class to
be abstract but have no candidate pure virtual functions for it, you could
declare the destructor to be pure virtual. It isn't clear to me why this
situation would arise, but it is allowed by the language definition.

If a class has one or more pure virtual functions, it should have a
virtual destructor. (If it has any pure virtual functions, it is intended to
be derived from, and so should have a virtual destructor.) I see no advantage
or disadvantage in making it pure virtual in that case, since the net effect
is the same either way.

For pure virtual functions other than the destructor, you may provide or
omit a function body. If you provide a function body, that function may
be called explicitly, such as:
	p->base::pure(); // invoke the base version explicitly
but it will never be invoked via the virtual function mechanism:
	p->pure(); // will never invoke the base version

You should document whether you provide a body for a pure virtual function,
and if so, under what circumstances it should be called. For pure virtual
destructors there are no options: you must provide the body and it will
always be called automatically. (If all objects are created on the heap
and never destroyed, you might get away without defining destructors, but
that is also a special case.)