If a derived class is deleted polymorphically, then its base class's
destructor must be declared virtual in order to properly,
polymorphically, destroy the derived class.

The only situation I can think of, where non-virtual base class
destructors would not be required, would be when the derived class is
used polymorphically, but not destroyed polymorphically (for example,
   derived *p=new derived;
   DoSomethingWithBase(p); // takes base *
   delete p;
are all in the same function).

Given that this is the case, why not make it part of the language
standard that:
- if a class has any virtual functions (including any inherited from
base classes), its destructor is automatically made virtual by the
compiler
- if neither the derived class nor its base classes have any virtual
functions, and the derived class destructor is not explicitly declared
virtual, then the derived class destructor is not virtual (as is
currently the case).

Actually, Scott Meyers sums this up nicely in "Effective C++":
"...many people summarize the situation this way:  declare a virtual
destructor in a class if and only if that class contains at least one
virtual function." (Meyers, Scott: "Effective C++", p. 45; published
by Addison-Wesley, 1992)  I'm simply suggesting that we take that
summary, and make it an enforceable part of the language.

Advantages:
- Doesn't require the programmer to remember to declare the base class
virtual, thereby helping avoid a common programming error.
- little overhead involved; usually one extra pointer dereference in
the vtbl implementation of virtual functions
- doesn't add virtual functions if there aren't any already

Disadvantages:
- doesn't address the problem of when a base class has no virtual
functions, and the derived class does - what to do about the base
class? (but then, that's still a problem in current language specs, so
nothing is lost by adding my proposed rule)
- may be some extra overhead if class is not expected to be destroyed
polymorphically (see example in my preamble)
- may break existing code (but not as badly as forcing only two valid
signatures for main()!), but in the worst case a full recompile will
fix it, without any code changes.

--
Jim Hyslop
jim.hyslop@leitch.com
"If you want to see the rainbow, you
gotta put up with the rain."
       -- Dolly Parton
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

jim.hyslop@leitch.com (Jim Hyslop) writes:

>... why not make it part of the language
>standard that:
>- if a class has any virtual functions (including any inherited from
>base classes), its destructor is automatically made virtual by the
>compiler

This has been suggested before.  However, given that compilers can and
often do issue warnings about classes with virtual functions and a
non-virtual destructor, there doesn't seem to be a big advantage in not
requiring the user to explicitly write `virtual' in such cases.  There
are certainly disadvantages in making such a change, e.g. the
difficulty involved in porting code written for compilers that support
this change to older compilers (particularly for people who don't know
about the change, but just find that the program they are trying to
port dumps core...)

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]