ecs@indirect.com (Ed Snible) writes:

>/*
>   With the following heirarchy, my compiler complains about C's destructor
>   trying to call A's destructor, but not about D's generated destructor
>   trying to call A's destructor.  Why?
>*/

Because D's destructor never gets generated.
The destructor will only be generated if it is needed.
Try adding `D d' at the end of your example - your compiler
should then complain about D's generated destructor trying
to call A's destructor.

--
Fergus Henderson - fjh@munta.cs.mu.oz.au
all [L] (programming_language(L), L \= "Mercury") => better("Mercury", L) ;-)

/*
   With the following heirarchy, my compiler complains about C's destructor
   trying to call A's destructor, but not about D's generated destructor
   trying to call A's destructor.  Why?
*/

class A {
public:
   ~A() {}
};
class B: virtual A {};
class C: public B {
public:
   ~C() {}  // Error: Destructor for 'A' is not accessible in function C::~C()

};
class D: public B { };

/*
   It seems to me from ARM 12.2c that it should be impossible for either
   the generated or the explicit destructor to work.  This seems to make
   private inheritence from any class with a virtual base in its
   heirarchy impossible.  What is the correct behavior?

   I am using Borland C++ 4.5 as my compiler.
*/

Ed Snible
ecs@indirect.com

In article 1tt@indirect.com, ecs@indirect.com (Ed Snible) writes:
>/*
>   With the following heirarchy, my compiler complains about C's destructor
>   trying to call A's destructor, but not about D's generated destructor
>   trying to call A's destructor.  Why?
>*/
>
>class A {
>public:
>   ~A() {}
>};
>class B: virtual A {};
>class C: public B {
>public:
>   ~C() {}  // Error: Destructor for 'A' is not accessible in function C::~C()
>
>};
>class D: public B { };

It's a compiler bug. Class D has the same problem as C, and should also be
reported as an error: base-class destructor not accessible.

---
Steve Clamage, stephen.clamage@eng.sun.com