TITLE: rule-of-thumb: using virtual destructors

(Newsgroups: comp.lang.c++.moderated)

PROBLEM: rmartin@oma.com (Robert C. Martin)

The rule, from my point of view, is that any class that manages any
kind of resource (e.g. memory storage, semaphore, file, data structure
consistency, etc) must have explicity defined copy semantics (i.e.
copy constructors and assignment operators) as well as a destructor.

Moreover, destructors should almost always (read that as: "DAMN NEAR
ALWAYS  (read that as: ALWAYS)) have a virtual destructor.


RESPONSE: Paul J. Lucas

If a class is light-weight, is part of an implementation, i.e.,
all instances are created/destroyed by you, or it just makes no
sense to derive from a class, you do not need a virtual
destructor.


RESPONSE: "Roger L. Cauvin" <rcauvin@natinst.com>

Right.  It all depends on the type of object-oriented programming you 
are doing.  If your design uses parametric polymorphism 
(extensibility achieved by class and function templates, as in STL), you 
generally should avoid virtual destructors (and virtual functions of 
any sort).  If, on the other hand, your design uses inherent 
polymorphism (deep inheritance structure, lots of virtual functions, and 
abstract base classes), then virtual destructors are vital.


RESPONSE: rmartin@oma.com (Robert C. Martin), 15 Jul 96

Take care.  One does not need *any* kind of polymorphism to have their
program crash for lack of a virtual destructor.  Virtual destructors provide
three critical pieces of information about the object being destroyed.

1. The address of the destructor
2. The size of the block being deleted.
3. The address of the block being deleted.

If you don't use virtual destructors, and the object being destroyed has any
base classes, then the chance that one of these three items will be wrong
is non-zero.  The first will probably create memory leaks.  The other two
will probably trash the heap.


RESPONSE: p j l @wizard.arc.nasa.gov (Paul J. Lucas)

[snip] I despise rules of thumb because they preclude thought.
Such rules are for newbies only, at most.

If a class is light-weight, is part of an implementation, i.e.,
all instances are created/destroyed by you, or it just makes no
sense to derive from a class, you do not need a virtual
destructor.


RESPONSE: rmartin@oma.com (Robert C. Martin)

[snip]

You may despise rules of thumb, but this one is a good one. 

Consider the following classes that are light-weight, part of an
implementation, all instances are created/destroyed by me, and it makes
no snese to derive any further from them.

class A
{
  int a;
};

class B
{
  int b;
};

class C : public a, public b
{
};

A* ap = new C;
delete ap;
B* bp = new C;
delete bp;

This stretch of code is undefined because neither A nor B have
a virtual destructor.  i.e. on many processors this will crash hideously.

OK, so we can add one more clause to your non-rule-of-thumb above, to the
effect that "and the classes do not have multiple bases".  

Anyway, a rule of thumb is not meant to preclude thought.  It is meant
to provide a default prior to the application of thought.  i.e. if I can't
figure out a good reason *not* to make the destructor virtual, then I will
make it virtual.