Path: utzoo!attcan!uunet!brunix!sdm
From: sdm@cs.brown.edu (Scott Meyers)
Newsgroups: comp.lang.c++
Subject: Faulty Ambiguity Detection with Virtual Bases
Message-ID: <54733@brunix.UUCP>
Date: 29 Oct 90 16:58:26 GMT
Sender: news@brunix.UUCP
Reply-To: sdm@cs.brown.edu (Scott Meyers)
Organization: Brown University Department of Computer Science
Lines: 49

Normally, C++ doesn't complain about potential ambituity, only ambiguity at
a point of call.  With MI, for example, if a function is inherited through
two paths, the function to be called must normally be disambiguated only
when it is called.  As the ARM puts it (p. 206):

    Only the *use* of a name in an ambiguous way is an error, however;
    combining classes that contain members with the same name in an
    inheritance scheme is not an error.

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.

    1.  Does anybody feel this is not an error in cfront?

    2.  Can anybody explain to me why it should make a difference whether a
        base class is virtual or not in the above example?


Thanks,

Scott
sdm@cs.brown.edu