Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>Classes with <code>virtual private</code> base should not be derived from, per <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_closed.html#7" rel="nofollow">this</a> at the C++ SWG. The compiler is doing the right thing (up to a point). The issue is not with the visibility of A from C, it's that C should not be allowed to be instantiated at all, implying that the bug is in the first (default) construction rather than the other lines.</p> <blockquote> <ol> <li>Can a class with a private virtual base class be derived from?</li> </ol> <p>Section: 11.2 [class.access.base]<br> Status: NAD Submitter: Jason Merrill Date: unknown</p> </blockquote> <pre><code>class Foo { public: Foo() {} ~Foo() {} }; class A : virtual private Foo { public: A() {} ~A() {} }; class Bar : public A { public: Bar() {} ~Bar() {} }; </code></pre> <blockquote> <p>~Bar() calls ~Foo(), which is ill-formed due to access violation, right? (Bar's constructor has the same problem since it needs to call Foo's constructor.) There seems to be some disagreement among compilers. Sun, IBM and g++ reject the testcase, EDG and HP accept it. Perhaps this case should be clarified by a note in the draft. In short, it looks like a class with a virtual private base can't be derived from.</p> <p>Rationale: This is what was intended.</p> </blockquote> <p>btw the Visual C++ v10 compiler behaviour is the same as noted in the question. Removing <code>virtual</code> from the inheritance of <code>A</code> in <code>B</code> fixes the problem. </p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    1. COThanks. But first of all, removing virtual does NOT fix the problem, because the problem is not to make this thing compile - the problem is to understand what's going on. And second, the quote from the closed issue you mentioned does NOT imply that a class with a virtual base cannot be derived from, at least not clearly enough. I mean in the sentence "This is what what was intended" I can't see what 'this' refers to. But if you are right, and it cannot be derived from, then C x; should fail to comile as well, but it doesn't. So this is still a bug, and my question remains open.
      singulars
    2. CO@Armen - I don't know, seems pretty categorical to me. 'In short, it looks like a class with a virtual private base can't be derived from. Rationale: This is what was intended.' The info also states that compilers vary in how they cope with this, so it's not surprising that Visual C++ is inconsistent as well.
      singulars
    3. COI do appreciate that without friends, it is obvious that a class with a virtual private base cannot be derived from. If we consider friends a special case, then special wording is needed in the standard, otherwise with default definitions of friend and virtual inheritance, I suppose that the above code was MEANT to compile by the standard. If not, this case should have been explicitly mentioned. An in ANY case, either ALL three lines in main should fail, or all succeed. Otherwise, I cannot call the phenomenon anything but a bug. Has anyone tried this code on other compilers btw?
      singulars
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload