Difference in Destructor calling mechanism between vc++ 6.0 and vc++ 2005

Amal P

Dears,

I have a question regarding the destructor calling mechanism difference between Visual C++ 2005 and Visual C++ 6.0. When i write following code in Visual C++ 6.0 it fails to compile. But when i write it in Visual C++ 2005 it is working well. What could be the reason for this difference The constructor/destructor of virtual base class is called by "most derived class". Here the most derived class is TryDerive and it is derived from class NonDerivable. Class NonDerivable is derived from DisableDerive virtualy. Since the destructor of class DisableDerive is private when the class TryDerive(Most derived class) try to call this function the compile time error is issued by VC++ 6.0 compiler and the VC++ 2005 complile this code and the destructurs are getting called correctly.

Pease see the code below.

Code Snippet

class DisableDerive // A base class

{

public:

DisableDerive(){ std::cout<<"DisableDerive::DisabeDerive()\n"; } // Made the constructor as private

private:

~DisableDerive()

{

std::cout<<"DisableDerive::~DisableDerive()\n";

}

friend class NonDerivable; // Made NonDerivable as friend so that it can access private constructor

};

class NonDerivable: virtual protected DisableDerive // Intermediate class - Virtual base

{

private:

int m_nVal;

public:

NonDerivable()

{

std::cout<<"NonDerivable::NonDerivable()\n";

m_nVal = -1;

}

~NonDerivable()

{

std::cout<<"NonDerivable::~NonDerivable()\n";

}

void SetValue( int nVal ){ m_nVal = 10; }

};

class TryDerive: public NonDerivable // Deriving from non derivable class

{

public:

TryDerive()

{

std::cout<<"TryDerive::TryDerive()\n";

}

~TryDerive()

{

std::cout<<"TryDerive::~TryDerive()\n";

}

};

int main()

{

TryDerive a;

return 0;

}

Compiler outputs

VC++ 6.0:

--------------------Configuration: CompileTest - Win32 Debug--------------------
Compiling...
CompileTest.cpp
D:\CompileTest\CompileTest.cpp(53) : error C2248: 'DisableDerive::~DisableDerive' : cannot access private member declared in class 'DisableDerive'
D:\CompileTest\CompileTest.cpp(11) : see declaration of 'DisableDerive::~DisableDerive'
Error executing cl.exe.

CompileTest.exe - 1 error(s), 0 warning(s)

VC++ 2005

1>------ Build started: Project: CompileTest, Configuration: Debug Win32 ------

1>Compiling...

1>CompileTest.cpp

1>Linking...

1>Embedding manifest...

1>Build log was saved at "file://c:\Documents and Settings\Amal\My Documents\Visual Studio 2005\Projects\CompileTest\CompileTest\Debug\BuildLog.htm"

1>CompileTest - 0 error(s), 0 warning(s)

========== Build: 1 succeeded, 0 failed, 0 up-to-date, 0 skipped ==========

Thanks,

Amal P.

Sarath.

I could not track down the exact reason.. Anyway here's my explanation.

Even the private constructors declared will be accessible to the NonDerivable class. then after you are publically deriving from the NonDerivable class using public visibility. Which should work well. I think it's bug of Visual C++ 6.0 compiler which is corrected in the C++ compiler with Visual Studio 7.x.

BTW. The virtual derivation used while we having mupltiple base classes (diamond inheritance). Here what's the relevance for it

Amal P

Dear,

I am actually asking about how the private destructor gets called by the most derived class.

May be it could be possible because the virtual base destructor for TryDerive can call the private destructor of base class.

But still I expect someone will answer about the difference in behaviour of VC++ 6.0 and VC2005.

Thanks for your help,

Amal P.

Amal P

Hi,

I tried to compile the above code with GCC also. Latest GCC compiler also shown same error as visual studio 6.0. And visual studio 2005 compiles this code successfully. Can anyone tell me what is the reason behind this Is it an error with Visual Studio 2005 Or did Microsoft deliberately done this for some reason

Thanks and regards,
Amal P.

einaros

I'm pretty sure this is a known problem in the compiler (I seem to recall other posts about it in the past, and successive additions to the bug site at http://connect.microsoft.com). In either case, the above should fail to compile, and I believe its addressed in the next VS version, Orcas. It's not fixed in VS2005 SP1, which is somewhat of a shame, but if MS happens to release further service packs for that, I'm sure it'll be included.

einaros

Thinking closer about this, it seems that you are putting yourself at more of a risk than initially required by introducing NonDerivable with virtual protected inheritance from DisableDerive. Cluttering your layout with such, largely misunderstood and misused features of the language is likely to have the compiler misbehave at some point or the other. The issue in this case doesn't even seem to be related to the known bugs I mentioned in my previous post.

Anyhow, the *clean* solution to the problem would be to skip DisableDerive entirely, and simply make NonDerivable's destructor private.

Amal P

This mechanism is done for implementing a final class. If I remove the DisableDerive and just make NonDerivable's destructor private it will not be possibe to create the object of class NonDerivable. But in the current method it is possible to make the object and it will not be possible to derive in Visual Studio 6.0 and GCC. So I hope using the solution you mentioned wont do my requirment. And more than that if I make constructor of DisableDerive private it would be a *clean* solution. But I just wanted to know wheather it is a problem with visual studio 2005. And I just wondered because the compiler worked in an expected way in a lower version and in an unexpected way in higher version.

Thank you very much for your reply. I have been waiting for a long time to get one.

Thanks and regads,

Amal P

einaros

Amal P wrote:

But I just wanted to know wheather it is a problem with visual studio 2005. And I just wondered because the compiler worked in an expected way in a lower version and in an unexpected way in higher version.

IMHO it's a compiler problem, but I don't think that will help you very much with regard to your current project. You should still head over to the connect site and search for similar bugs, or alternatively report it for reviewing. It's not fixed in the public Orcas beta, but it may have been addressed in MS' internal codebase.