Martin,
Thanks for looking at this.
10.1.4 has this example, which it claims is legal (incidentally my g++-3.0
-pedantic agrees):
struct L { int next; };
struct A : L {};
struct B : L {};
struct C : A, B { void f (); };
void C::f () { A::next = B::next; }
If your previous transformation were also applicable here, this would be
equivalent to "this->L::next = this->L::next;" - which is clearly not
well-formed. Have I missed some relevant distinction in the Standard
between data member lookup and member function lookup?
While the Standard paragraph isn't exactly clear, I don't think that the
members of the set that is constructed under 10.2.2 can be of the form
"HwQueue's void pop() member". Rather, they have to include information
about which subobject they involve. In this way, the set produced by a
lookup for undecorated "pop();" would be:
{ "direct base class ISImq's direct base class HwQueue's void pop()",
"direct base class ISPmq's direct base class HwQueue's void pop()"}
Which isn't a singleton set, and so the program wouldn't be well-formed.
This all hinges on "name lookup begins in the scope of the
nested-name-specifier" implying something like "name lookup does not
consider sub-objects outside the scope of the nested-name-specifier".
Cheers,
-----Original Message-----
From: Martin v. Loewis [mailto:[EMAIL PROTECTED]
Sent: Thursday, January 10, 2002 12:15 AM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; debian-gcc@lists.debian.org
Subject: Re: -pedantic reports ambiguous base
> Without -pedantic there is not even a warning (even with -W -Wall).
> 10.2.1 says "for a qualified-id, name lookup begins in the scope of
> 10.2.the nested-name-specifier". In which scope, I don't think the
> 10.2.reference to pop() or HWQueue, for that matter, is ambiguous.
This is caused by the fragment in cp/init.c
/* Convert 'this' to the specified type to disambiguate conversion
to the function's context. Apparently Standard C++ says that we
shouldn't do this. */
if (decl == current_class_ref
&& ! pedantic
&& ACCESSIBLY_UNIQUELY_DERIVED_P (type, current_class_type))
It seems there are several interpretations of 10.2/1. GCC's
interpretation is that, indeed, lookup starts in ISPmq, and finds
HwQueue::pop. So the call you have written is equivalent to
this->HwQueue::pop();
which is ambiguous.
It would be good if you could achieve independent clarification,
e.g. through comp.std.c++. If people are of different opinion there as
well, consider filing a Defect Report. Notice that variations of this
have been discussed repeatedly in comp.stdc.c++; you may want to read
the archives.
Regards,
Martin
*********************************************************************
This e-mail and any attachment is confidential. It may only be read, copied and
used by the intended recipient(s). If you are not the intended recipient(s),
you may not copy, use, distribute, forward, store or disclose this e-mail or
any attachment. If you are not the intended recipient(s) or have otherwise
received this e-mail in error, you should destroy it and any attachment and
notify the sender by reply e-mail or send a message to [EMAIL PROTECTED]
*********************************************************************
