Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!apple!fernwood!lia!jgro
From: jgro@lia (Jeremy Grodberg)
Newsgroups: comp.lang.c++
Subject: Re: Faulty Ambiguity Detection with Virtual Bases
Message-ID: <1990Oct30.194006.833@lia>
Date: 30 Oct 90 19:40:06 GMT
References: <54733@brunix.UUCP<
Reply-To: jgro@lia.com (Jeremy Grodberg)
Lines: 55

In article <54733@brunix.UUCP< sdm@cs.brown.edu (Scott Meyers) writes:
<Normally, C++ doesn't complain about potential ambituity, only ambiguity at
<a point of call.  [...] But consider the following example, where function
<foo is inherited through two paths in class Bottom:
<
<    class VBase {
<    public:
<      virtual void foo() = 0;
<    };
<
<    class Middle1: virtual public VBase {
<    public:
<      virtual void foo();
<    };
<
<    class Middle2:  virtual public VBase {
<    public:
<      virtual void foo();
<    };
<
<    class Bottom: public Middle1, public Middle2 {
<    };
<
<AT&T cfront 2.0 and Sun's cfront 2.1 (beta) both give the following error:
<
<    "ambiguity.C", line 16: error: virtual base: ambiguous Middle1::foo()
<                                                 and Middle2::foo()
<
<On the other hand, g++ 1.37 takes it without complaining.  Furthermore, if
<either Middle1 or Middle2 is made a nonvirtual base class, then cfront is
<happy, too, even though the ambiguity remains.
<

The ARM, on page 235, says "To avoid ambiguous function definitions, all
redefinitions of a virtual function from a virtual base class must occur
on a single path through the inheritance structure."  This explains the
behavior of CFront.  However, this quote is taken from the commentary on
how virtual base classes with virtual functions could be implemented,
not from any section which is part of the ANSI base document, so it has
no formal status as defining the language.  The section that is part of
the formal specification does not address this issue at all (as far as I
can find).

In short, the reason CFront complains is because there is only one
pointer slot for a virtual function of a virtual base, and the compiler
can't put both Middle1::foo() and Middle2::foo() in the one slot.

g++ either uses a different mechanism for virtual function tables
(doubtful), fills the table's slot with a pointer to a function which 
returns a run-time error message (reasonable), or just puts one of the two 
functions in the table (a bug).

-- 
Jeremy Grodberg      "I don't feel witty today.  Don't bug me."
jgro@lia.com