Click here to Skip to main content
15,886,422 members
Articles / Programming Languages / C++
Article

BUG in Visual C++ access for destructors with virtual base classes

Rate me:
Please Sign up or sign in to vote.
0.00/5 (No votes)
5 Apr 2000 62.4K   16   6
When inheriting from a virtual base class the access specifier for the destructor is ignored

Introduction

This bug appears in VC6 SP3, and possibly earlier versions as well.

When inheriting from a virtual base class the access specifier for the destructor is ignored

To demonstrate, if the word virtual is commented out as shown below in the declaration of class B, this program correctly produces the error message

xxx.cpp(28) : error C2248: 'B::~B' : cannot
access protected member declared in class 'B'
xxx.cpp(23) : see declaration of 'B::~B'

If the word virtual is un-commented then the program builds without error messages despite the destructor being declared private

The offending code

#include "stdafx.h"

class A {
protected:
    ~A() {}
};

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

int main(int argc, char* argv[])
{
    B b;
    return 0;
}

As a bit of history, I am implementing some smart pointers and want to ensure that the smart-pointer target object cannot be created locally on the stack, nor do I want to be able to explicitly call delete on a pointer to such an object. Hence I want the destructor to be private. However, this fails (as shown above) when I am inheriting from a virtual base class.

License

This article has no explicit license attached to it but may contain usage terms in the article text or the download files themselves. If in doubt please contact the author via the discussion board below.

A list of licenses authors might use can be found here


Written By
United States United States
This member has not yet provided a Biography. Assume it's interesting and varied, and probably something to do with programming.

Comments and Discussions

 
GeneralVC++ compiler bug Pin
isheu26-Aug-08 2:28
isheu26-Aug-08 2:28 
QuestionShould be virtual? Pin
AlexMarbus10-May-01 2:50
AlexMarbus10-May-01 2:50 
AnswerRe: Should be virtual? Pin
10-May-01 6:09
suss10-May-01 6:09 
GeneralBeside the point Pin
Roger Onslow10-Apr-00 15:45
Roger Onslow10-Apr-00 15:45 
>Yes, the code will compile

It shouldn't

>and will allow you to create the target on the stack

It shouldn't

>but it will not allow you to call the destuctor explicitly.

That is beside the point. You (correctly) cannot call _any_ private function explicitly. That all works fine. It is the implicit call where the bug bites .. and lets face it, one almost never explicitly calls a destructor.

>I can see that you might want to prevent an object being
>created on the stack

yeup. lots of good reasons for that. especially when using smart pointers.

>but how did you intend to allow it
>to be created on the heap and still be able to delete it
>(which would not be allowed with a private destructor)?

a target for a smart pointer deletes itself .. indeed, you don't ever want it to be directly deleted, that defeats the smarts of smart pointers.

and one can still create the object on the heap with new. I sometime even want to stop that, and only allow creation view a member of the smart pointer class (which is a friend of the target). That way I have complete control of the creation and destruction.

But that has nothing really to do with the bug exhibited here.

Trust me, if it had correctly produced errors, I would have had a nice safe smart pointer class that would have stopped me from doing bad thinkgs (like have local vars etc). As it is, I wrote my smart pointer class a little differently (without virtual inheritance) to get around this bug, but still with protected destructors etc and it all works just fine now.

>Surely the smart pointer will eventually try to delete its
>contents?

Of course. It is able to do so because it is a friend of the target class, and so can call the Release function of the target which in turn deletes itself when the reference count goes to zero. Pretty standard stuff for smart pointers.

>The only way around this I know of is to delete via a
>pointer to a base that has a public destructor...

no .. you can also ask the object to commit suicide. there are other ways too (eg. static function that calls delete)

>Incidentally, shouldn't the destructor of A also be >declared virtual, as you are deriving from A

can be .. doesn't need to be. the bug still happens either way.

I presented the minimum code to exhibit the bug. If I had included all the guts of my smart pointer implementation, etc if would have clouded an otherwise simple example.
GeneralC++ Compiler bug Pin
Member 112710-Apr-00 0:05
Member 112710-Apr-00 0:05 
GeneralC++ compiler BUG Pin
Alex Turc6-Apr-00 1:25
Alex Turc6-Apr-00 1:25 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.