Ambiguous base class

Ambiguous base class

[Matt Austern]

gcc rejects the following snippet:
   struct A { int x; };
   struct B1 : public A { };
   struct B2 : public A { };
   struct D : public B1, public B2 { };

   int f(D d) {
   #ifdef 1
     return d.B1::A::x;
   #else
     return d.B1::x;
   #endif
   }

As the #ifdef suggests, what gcc dislikes is the
B1::A::x part.  It accepts B1::x, but says that
B1::A::x is ambiguous.

It's always possible that I've missed something
in the Standard, but this seems wrong.  As far as
I can tell from my cursory reading of 3.4.3,
B1::A::x ought to be fine: it should look up A
in B1's scope, and x in B1::A's scope.

So, the usual two questions:
(1) Is there text in the standard that says my
reading is wrong?  Is there an argument that gcc's
behavior is right?
(2) If the answer to #1 is 'no': is this a known
bug?

			--Matt

Re: Ambiguous base class

[Matt Austern]

On Tuesday, September 10, 2002, at 09:20 AM, Mark Mitchell wrote:

>> 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.
>
> I think that's best; I took a brief look this morning and couldn't
> find whatever it was that had convinced me before.

OK, I've posted to c++std-core.  We'll see if anyone there can
give us a definite answer.  If it turns out that the compiler's
behavior is wrong, I'll let this list know.

			--Matt

Re: Ambiguous base class

[Mark Mitchell]

> 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.

I think that's best; I took a brief look this morning and couldn't
find whatever it was that had convinced me before.

-- 
Mark Mitchell                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com

Re: Ambiguous base class

[Nathan Sidwell]

Matt Austern wrote:

> The relevant part of the Standard is 3.4.3, I think. I read it,
No, 3.4.5 applies for lookup after . and ->
The relevant para appears to be 4, which doesn't explicitly mention
	ptr->IntermediateBase::FinalBase::member
but does say that the class name doesn't have to be a unique base
of the class type of the object expression, as long as
the entitiy named by the qualified id are members of the class type
of the object expression and not ambiguous.
The class type of the object expression is the static type of the
thing before the ->.

<handwaving>
The std seems to consider qualified ids as
	context-type-thing::(qualified-id-chain)::final-thing
rather than
	((context-type-thing::qualified-id0)::qualified-idn)::final-thing

nathan

-- 
Dr Nathan Sidwell   ::   http://www.codesourcery.com   ::   CodeSourcery LLC
          'But that's a lie.' - 'Yes it is. What's your point?'
nathan@codesourcery.com : http://www.cs.bris.ac.uk/~nathan/ : nathan@acm.org

Re: Ambiguous base class

[Matt Austern]

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

Re: Ambiguous base class

[Mark Mitchell]

> 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...

(FYI, EDG 3.0 rejects your test case as well.)

-- 
Mark Mitchell                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com

Re: Ambiguous base class

[Matt Austern]

On Friday, September 6, 2002, at 01:25 PM, Wolfgang Bangerth wrote:

>
> Matt Austern writes:
>> (2) If the answer to #1 is 'no': is this a known bug?
>
> Yes, its c++/525.



Hm, that seems slightly different.  I'm puzzled because
the compiler is treating D1::Base::x differently from
D1::x (where Base is an unambiguous base class of D1).
It doesn't involve the -pedantic flag.  I see it in
the TOT compiler.

525 is different in that: (a) it has nothing to do with
the multiple qualification syntax; (b) it only manifests
itself with the -pedantic flag; (c) it's marked as having
been fixed in 3.1.

It does look like 525 may be related to what I'm seeing,
but I don't think it's a duplicate.

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;
   }
Note that the compiler accepts it if you change
B1::A::x to B1::x.  Unless I've missed something,
this ought not to make a difference.

			--Matt