Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!ucbvax!hplabs!hpfcso!hpfcbig!jenings
From: jenings@hpfcbig.SDE.HP.COM (Byron T. Jenings Jr.)
Newsgroups: comp.lang.c++
Subject: Re: True Virtual / Exceptions
Message-ID: <7180012@hpfcbig.SDE.HP.COM>
Date: 8 Feb 90 06:26:40 GMT
References: <4800082@m.cs.uiuc.edu>
Organization: HP SESD, Fort Collins, CO
Lines: 29


 Andrew Koenig <ark@alice.UUCP> writes:
|Therefore, it doesn't make sense to have a pure virtual
|destructor, as it would preclude destroying objects not
|only of that class but of any class derived from it.

Only if you take a compiler implementer's view instead of a user's
view.  I hit this as well, because I was trying to specify:

This is an abstract base class that cannot exist, and so has nothing
but pure virtual functions.  Since it cannot exist, it has no
destructor, so there's obviously no base class destructor for derived
classes to call.

Since all of the above is specified in the class declaration, the
compiler could easily treat a pure virtual destructor the same as a
nonexistent destructor, with the exception of putting a placeholder
entry in the virtual function table for it.

What cfront2.0 really did, however, was to compile my virtual
destructor OK, but generated calls to the "nonexistent" base class in
each derived class's destructor.  This seems inconsistent, since the
function both exists and doesn't exist at the same time.

I can see why cfront does what it does, however, since this way the
compiler doesn't have to bother to look up whether the base class's
destructor was pure.  Probably keeps the code simpler.

Or, maybe there's some conceptual truth that I'm overlooking...