Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!microsoft!ilanc
From: ilanc@microsoft.UUCP (Ilan CARON)
Newsgroups: comp.lang.c++
Subject: Re: Faulty Ambiguity Detection with Virtual Bases
Message-ID: <58641@microsoft.UUCP>
Date: 30 Oct 90 18:24:06 GMT
References: <54733@brunix.UUCP>
Reply-To: ilanc@microsoft.UUCP (Ilan CARON)
Organization: Microsoft Corp., Redmond WA
Lines: 46

In article <54733@brunix.UUCP> sdm@cs.brown.edu (Scott Meyers) writes:
>    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 {
>    };
>
>    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?


[Apologies if this is the nth response... our newsfeed is abysmally slow]

This definition is in error since there is only *one* virtual function
table slot in VBase's vft for function foo() -- hence when creating an
instance of Bottom (which has only *one* embedded instance of VBase
because it's derived from virtually), the compiler can't know which
overriding function, Middle1::foo() or Middle2::foo(), to prefer.  C++
has no rules for resolving this particular ambiguity (note that
dominance is irrelevant here).  (Hence instances of Bottom can't be created,
hence the definition is in error).

On the other hand, the non-virtual case is fine.  There's no problem when
creating an instance of Bottom: the vft of the Vbase part of Middle1 gets
initialized with Middle1::foo(), similarly the Vbase part of Middle2.

Of course, a *reference* to foo() through an instance of Bottom needs
to be disambiguated: as in, a_bottom.Middle1::foo().

--ilan caron (uunet!microsoft!ilanc)

P.S. Yeah, I just *love* virtual inheritance...