🚀 go-pugleaf

In article <77210004@hpclscu.HP.COM> shankar@hpclscu.HP.COM (Shankar Unni) writes:
>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).

Base class destructors called from within a derived class destructor are
not called using the virtual mechanism.  It's the equivalent of calling
bv->B::foo() instead of b->foo().  If you saw an out-of-line call I
suspect you ran into the cfront hack which prohibits inlining in
expressions of a certain complexity (I believe no more than 2 inlines
per expression, though I may have the number wrong.)  If you saw an
out-of-line virtual call, you ran into a deadly bug which will cause
all virtual destructors to die the recursive death.

In any case, you can't make the destructor virtual unless you define it.
The compiler generated constructor won't be virtual unless it has a
base class with a virtual destructor.  Defining a pure virtual destructor
with an inline empty body will also work, though, as mentioned above,
cfront may not optimize it away.

Mike Ball
TauMetric Corporation