Boost logo

Boost Testing :

From: Jim Douglas (jim_at_[hidden])
Date: 2005-10-19 16:44:05


I am keeping an open mind and I am prepared to be convinced if you can
provide the evidence. Can you give a working test case - perhaps in a
separate file - that demonstrates the incorrect behaviour with a virtual
dtor, and the necessary correction that justifies your current approach.
That way I can try it on my platform/compiler to see if I experience the
same problems.

Yes I see the logic in the code below and can confirm that it will not
compile due to the protected dtor of A.


Robert Ramey wrote:
> Jim Douglas wrote:
> Here is the program:
> class A {
> virtual f() = 0;
> protected:
> ~A(); // note::destructor NOT virtual
> };
> class B : public A
> {
> public:
> ~B();
> virtual f();
> };
> main() {
> A *MyPtr;
> MyPtr = new B; // this is perfectly legal and very useful
> delete MyPtr; // only calls the dtor for A
> // nope: fails to compile with syntax error here
> }
> It fails to compile at the point where an error would otherwise occur.
>>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
> Nope: It will still fail to compile - exactly as I intended.
>>>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.
> nope: In the real situation I have things are a little bit more problematic
> class A {
> ...
> };
> // B is defined in a DLL
> class B {
> };
> If the code for B has been explicitly unloaded, the Vtable of a has an
> invalid pointer
> and the program fails. This is why I wanted to explicitly forbid calling
> the destructor
> through the base class - which I have been able to do.
> I realize that this isn't customery and maybe is worth a warning - but I
> should be able to
> turn the warning off.
>>(Please don't take this the wrong way)
> Don't worry, I'm used to it.
>>Because your code in its present form violates every C++ coding standard
>>ever written.
> Hmmm - that's a pretty sweeping statement. I havn't seen issues addressed
> by
> dynamic loading and unloading of code even addressed by any of the
> references you mention.
> For that matter I don't know if the are even addressd by the C++ standard.
> Nevertheless, this is currently being done by some users of the
> serialization library and the
> failure to forsee it created some bugs. In the course of fixing these
> bugs - (very hard to
> track down) virtual was removed from the derived class destructors and the
> above was
> used to trap this behavior at compile time.
> Though it might not seem apparent, I am aware of the rationale described by
> the authors
> you mention. I don't know that they have considered cases like this. I
> believe that the idiom
> represented above will produce the same benefit (assuring that the most
> derived destructor
> is being called in a way that is more effective in this context.
>>That's why the warning is hard-coded into the GNU compiler.
> Hmmm - maybe that's why its only a warning or maybe that's why its the only
> compiler
> that makes this complaint.
> Robert Ramey

Boost-testing list run by mbergal at