🚀 go-pugleaf

> It is a little-known (and perhaps unfortunate) fact that pure virtual
> functions can be defined.  They can only be called through the
> explicitly qualified name, e.g.,
> 
> 	Base*	bp = new Derived;
> 	bp->Base::f();
> 
> would call Base::f() if it has been defined, and cause a link error
> otherwise.  The destructor is a slightly special case (:-)), since the
> compiler automatically generates the equivalent of an explicitly
> qualified call to it in the destructor of the derived class.
> 
> An alternative way to define the language would be to disallow
> defining pure virtual functions and (therefore) disallow pure virtual
> destructors.  This would give the programmer somewhat less flexibility
> but would not leave the compiler wondering whether a pure virtual
> function was going to be defined or not.

Yes, I remember filing a bug report about this, not realizing it was a
feature :-(.

However, the point (and it's not one that I'm going to beat around a lot -
this was mostly an information query), I think, was that he wanted to have
a destructor defined in a way such that *nothing* was called on behalf of
the base class component of the object.

Stephen Clamage writes:

> I really don't see what problem this user is trying to solve.  No class
> is required to have a destructor, so if you don't want a destructor
> called for class Base, don't define one.

But that's precisely the problem: if you don't define a destructor for a
class, *cfront will define one for you*; and call it when the object is
destroyed. This destructor happens to be a null inline, so when destroying
a standalone object of that class, nothing happens; however, when
destroying an object of a derived class, when cfront gets around to the
base class component, it puts out an out-of-line call to the null
destructor (because it's virtual).

Anyway, never mind; I'm convinced...
----
Shankar Unni.