🚀 go-pugleaf

In article <47u94u$4of@bigboote.WPI.EDU>, parker@WPI.EDU (Chris Parker) wrote:
>>>Is virtualness inherited by destructors?  Does C++ automatically make all 
>>>applicable superclasses also have virtual destructor if they don't already?

No.

>   May I inquire when you would ever *not* want the destructor to be virtual?

Check out the FAQ under Question 75 (or thereabouts, the number may have 
changed slightly since my version), Cline's FAQ book under Questions 98-99, 
Scott Meyers' "Effective C++" (can't recall the section as I loaned the book 
to someone), C++PL2 pg 216, D&E concidentally also pg 216, etc.

Short answer: When the class has no other virtual functions and you'll never 
destroy derived objects through a base pointer.

(Related question: Should compilers warn you when you have a virtual function 
but a non-virtual dtor?  Answer: Not mandated, but encouraged as a "quality of 
implementation" issue.)

>Probably only in the leaf of the class heirarchy. Destroying the object above
>the leaf child without having a virtual destructor causes nothing but a 
>memory leak, and quite possibly pain and hardship.

That's an understatement.  Two major problems besides a simple memory leak: 
slicing and heap corruption, both of which break program correctness and are 
murder to debug.

>So, I propose that if that if at any point in a class
>heirarchy tree a destructor is declared virtual, all destructors in the tree
>are virtual because that is really what you are trying to ask for.  What do 
>you think?

No.  Say I have base B and derived D1 and D2.  Only D2 has a virtual dtor.  
Why should this imply that D1 ought to have one?  Or even B for that matter, 
if the D2 designer is anticipating further-derived objects will be accessed 
through D2 pointers but knows B pointers aren't used or contemplated?

(If you think this discussion is interesting, read the FAQ about 'when should 
operator= be virtual'.)

Herb


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Herb Sutter                 2228 Urwin, Ste 102         voice (416) 618-0184
Connected Object Solutions  Oakville ON Canada L6L 2T2    fax (905) 847-6019

---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]