🚀 go-pugleaf

In article <MATT.95Nov10115356@cyclops5.berkeley.edu>  
matt@cyclops5.berkeley.edu (Matt Austern) writes:
> In article <199511091835.NAA11661@starling.WPI.EDU> Chris Parker  
> <parker@owl.WPI.EDU> writes:
> 
> > I'm pretty convinced that all destructors should be virtual all the 
> > time (implied).  I can't find a single case where it would make sense 
> > to destroy an object and not have all proper cleanup happen.
> 
> [snip]  
> 
> if the extra overhead of virtual functions would be a problem, and if you
> don't expect your class to be used as a base for inheritance, then you
> shouldn't make the destructor virtual.

IMHO the famous non-virtual destructor pitfall is caused by a language
defect: currently, the language allows us to express that a member  
function is virtual, but is does not provide us with a way of expressing  
that a member function is non-virtual. Therefore, destructors can only be  
non-virtual by default. 
 
If we had a `nonvirtual' keyword, destructors could be made virtual by  
default and we would have an escape mechanism for the case in which that  
would result in an unacceptable overhead.  As I tried to show on  
comp.lang.c++ a few weeks ago, having a `nonvirtual' keyword could solve a  
few others problems as well - but I believe the non-virtual destructor  
pitfall is probably the most pressing one.
 
- Wil
---
[ 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. ]