Re: Ambiguous base class

[Matt Austern <austern at apple dot com>]

On Monday, September 9, 2002, at 11:35 PM, Mark Mitchell wrote:

> > Again, here is my example:
> >    struct A { int x; };
> >    struct B1 : public A { };
> >    struct B2 : public A { };
> >    struct D : public B1, public B2 { };
> >
> >    int f(D d) {
> >      return d.B1::A::x;
> >    }
> I looked at this in the standard recently (in connection with the new
> parser) -- but I don't remember what I read.
>
> What I do remember is that you're supposed to look at "B1::A::x" as
> two pieces: a nested-name-specifier (B1::A::) and an unqualified name.
> You resolve the nested-name-specifier to a class or namespace; in this
> case "A".  You then look for "x" in "A", and you can use "A" to
> disambiguate things, but "B1" is lost to you at this point.
>
> In other words, your case is no different than if you add in:
>
>  struct Z { typedef A ZA; };
>
>  return d.ZA::x;
>
> Now, I do wish I remembered what lead me to this conclusion...
Interesting.  If so, then obviously the compiler is behaving
correctly.

The relevant part of the Standard is 3.4.3, I think. I read it,
and didn't come to the same conclusion you did, but it's entirely
likely that I missed something.  I suppose that if neither of
us can point to definite wording, we should punt this over to
the committee and see if anyone there can give us a definite
answer.

			--Matt