• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 279
  • Last Modified:

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

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

In VC 6 SP3 (and probably earlier, don't know).

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

#include "stdafx.h"

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

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

int main(int argc, char* argv[])
{
    B b;
    return 0;
}
0
RONSLOW
Asked:
RONSLOW
1 Solution
 
RONSLOWAuthor Commented:
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.
0
 
SamHobbsCommented:
Where is that documented?
0
 
migelCommented:
Hi!
why virtual inheritance?
may be you want pure virtual base class? or one base class can be multy inherited in the derived one in your hieararchy?
0
Keep up with what's happening at Experts Exchange!

Sign up to receive Decoded, a new monthly digest with product updates, feature release info, continuing education opportunities, and more.

 
RONSLOWAuthor Commented:
migel .. I do not havea problem with virtual inheritance.  In my real world application it IS required (diamond-shaped hierachy).

However, this sample is the minimum to reproduce the problem.

The problem is that, because the destructor for B is private, it should not be able to be called, even IMPLICITLY when an object of class B goes out of scope (also cannot explicitly delete a B* pointer).

That is the desired behaviour for my app, as I do NOT want to be able to have local variables of my class, nor allow direct calls to delete pointers (the object deletes itself so a private destructor works ok).  I want to see the expected compiler error if I attempt to do this in my code.

But when there is a virtual base class somewhere in the hierachy, the 'privacy' of the destructor is ignored.  BUG!!!

0
 
migelCommented:
ok I see.
BUG is BUG :-)
you also can declare your default constructor (and any other) as protected to avoid stack object :-)
0
 
RONSLOWAuthor Commented:
migel:

If I decalre the contructor as private, then I canno create objects using new.

I know I could write a static member function to call new for me, but I'd rather not have to do that.

eg.

class B {
private:
  B() {}
public:
  static B* New() {
    return new B;
  }
};

then calling
  B* p = B::New();
would work and
  B* p = new B;
would fail.

But, despite other techniques (which I am using as a work-around) the bug on the desturctor access is still a BUG !!
0
 
ianBCommented:
I have closed this question with RONSLOW's comment since we may want to keep the question in the arhives.

IAn
Community Support @ Experts Exchange
0

Featured Post

Receive 1:1 tech help

Solve your biggest tech problems alongside global tech experts with 1:1 help.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now