Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ukma!rutgers!att!ihlpm!ejbjr
From: ejbjr@ihlpm.ATT.COM (Branagan)
Newsgroups: comp.lang.c++
Subject: Re: Virtual destructors
Keywords: virtual destructor portability
Message-ID: <3130@ihlpm.ATT.COM>
Date: 3 Mar 89 21:36:38 GMT
References: <551@hrc63.co.uk> <1430@cod.NOSC.MIL> <101@riunite.ACA.MCC.COM>
Organization: AT&T Bell Laboratories - Naperville, Illinois
Lines: 46

> I'm not sure what the "correct" semantics are myself, but I don't think it
> is a bug.
> 
> I say that only because I have just recently been looking into the handling
> of "virtual" in GNU G++ (and in particular the handling of "virtual" for
> destructors) and I can tell you that G++ seems to do pretty much the same
> thing as described above.  That is to say, if you have a base class which
> has an explicitly virtual destructor, then the destructor will get a entry
> in the vtable for that class.  Also, any classes derived from such a class
> also (apparently) have entries for *their* destructors put into *their*
> vtables (in the same slot number).  This seems to be true regardless of
> whether or not the destructors in the derived classes explicitly have the
> keyword "virtual" in their declarations.  Thus, it seems that these
> destructors (in the derived classes) in effect become "implicitly"
> virtual.

If a function (any function, including a destructor) is declared
virtual in a base class, it will be virtual in all classes derived
from that base class.  I have not been able to find an explicit
statement of this rule in Stroustrups's book (though it might be
there somewhere), but some the examples make this behavior clear -
for instance, check out the example in section 7.2.8 on virtual
functions.  Function `print' in class  `employee' is declared as
virtual; in class `manager', derived from `employee', `print' is not
explicitly declared virtual.  It certainly would not make sense
for a non-virtual function to hide virtual functions - things just
would not work right.  The only other alternative would seem to be to
generate an error message if a virtual function in a derived class
was not explicitly declared virtual - something which is now out
of the question for compatability reasons.

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?  Perhaps either all destructors
should be automatically virtual (which has minor performance
implications for classes with no derived classes), or the documentation
should strongly advise making destructors virtual (or at least discuss
virtual destructors and when/why they should be used).
-- 
Jim Branagan
(312) 416-7408 (work)
(312) 810-0969 (home)
Remember - Good planets are hard to find - Be kind to Mom.