Boost logo

Boost Testing :

From: Jim Douglas (jim_at_[hidden])
Date: 2005-10-19 14:30:30


Robert,

This is the kind of topic that the likes of Herb Sutter and Scott Meyers
would rant on for days. See below...

Robert Ramey wrote:
> Boost Compiler Status Error Log
> "Jim Douglas" <jim_at_[hidden]> wrote in message
> news:divu90$hv2$1_at_sea.gmane.org...
>
>>By far the most common warning seems to be the "virtual functions but
>>non-virtual destructor" which, if true, is something that perhaps should
>>be fixed? AFAIK there is not an option to suppress this warning in gcc
>>version 3.3.5 (or indeed any version of gcc).
>
> I've wondered about this myself.

To reuse your examples (in the best traditions of OOP ;-)

class A {
     virtual f() = 0;
protected:
     ~A(); // note::destructor NOT virtual
     ...
};

class B :: public A
{
public:
     ~B();
};

main() {

    A *MyPtr;
    MyPtr = new B; // this is perfectly legal and very useful
    ...
    delete MyPtr; // only calls the dtor for A
}

In the above example the delete would only clean up the base class A and
leave bits of the derived class B lying around in memory causing a
memory leak. If you make A's dtor virtual then it will clean up B correctly.

> The idea is to require calling of the derived base class rather and trap
> attempts
> to violate this constraint.

But that's exactly what happens with a virtual dtor. The derived class
dtor is called automatically. You _cannot_ get it wrong.

(This change was introduced to address some
> issues
> of "global" objects calling virtual functions during destruction which
> occured
> when DLLS containing data serializaitions are unloaded.)

The whole point of defining a virtual dtor is to ensure that the correct
destruction happens every time.

> Why is a warning justified in this case?

(Please don't take this the wrong way) Because your code in its present
form violates every C++ coding standard ever written. That's why the
warning is hard-coded into the GNU compiler.

Regards
Jim Douglas


Boost-testing list run by mbergal at meta-comm.com