🚀 go-pugleaf

In article <3130@ihlpm.ATT.COM>, ejbjr@ihlpm.ATT.COM (Branagan) writes:

> I think we could use some better documentation about virtual
> destructors though - its not obvious from the documentation that a
> destructor can be declared virtual - BUT when should a destructor
> not be virtual?  Can anyone give a reasonable example when the
> destructor for a derived class should not be called when an object
> from a base class is to be destroyed?

If you ever say `delete' to a pointer to a base class that
actually points to an object of a derived class, the base
class must have a virtual destructor.

This rule is actually a slight oversimplification, but it's
probably the right one to follow rather than trying to figure
out the obscure (and possibly nonportable) exceptions.

Why not make all destructors virtual?  Performance.  If there
are no other virtual functions in the base class, making the
destructor virtual adds a word of overhead per object.  This
can be substantial if you're defining little tiny objects.
Moreover, C++ tries to impose overhead in only the cases that
need it.

In principle, once you've declared a virtual destructor in a
base class, you do not need to redeclare it in any derived
classes unless you need to say something there.  However,
some versions of C++ have a bug that causes incorrect code to
be generated if there's a virtual destructor in the base class
and no destructor at all in the derived class.  Thus if you
have a virtual destructor in a base class, define a destructor
explicitly in all defined classes even if the destructor is empty.
You don't have to say it's virtual in the derived classes.
--
				--Andrew Koenig
				  ark@europa.att.com