Re: Accessing hidden members of a class (as in x.A::B::y instead of
x.y)
On Jul 27, 1:07 pm, "Alf P. Steinbach" <al...@start.no> wrote:
* James Kanze:
On Jul 26, 7:25 pm, Rajib <raji...@verizon.net> wrote:
If I have the following code
class B {
public: int b;
};
class C : public B {};
class E : public C, public B {};
int main() {
E x;
C y;
x.C::B::b++; //test3.cpp:14: error: =91B' is an ambiguous ba=
se of =91E'
y.b++;
y.B::b++;
return 0;
}
Why is this ambiguous? I thought the compiler would look up C
(and find it unambiguously) and then use that to look up C::B
(again finding it unambiguously).
So did I, and my first reaction is to say that you'd encountered
a compiler error. In the expression x.C::B::b++, B and b should
be looked up using qualified name lookup, which finds the B in
C, and the b in B. VC++ accepts this, and I seem to recall
other compilers in the past accepting it as well (but it is a
very distant past, so I'm not really sure). G++ complains as
written (which I think is an error),
No, it's probably correct; see my reply else-thread.
Comeau C/C++ 4.3.10.1 (May 29 2008 09:37:15) for ONLINE_EVALUATION_BETA1
Copyright 1988-2008 Comeau Computing. All rights reserved.
MODE:strict errors C++ C++0x_extensions
"ComeauTest.c", line 12: error: base class "B" is ambiguous
x.C::B::b++; //test3.cpp:14: error: =91B' is an ambiguous base o=
f =91E'
^
but accepts x.C::b++.
This seems to be correct.
Well, I won't argue about it. Mainly because I can't really
figure out what the standard is trying to say myself. And
because I don't consider it important, since such cases
shouldn't ever really occur in reasonable code. (Of course, if
you're writing a compiler, that's a different issue.)
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34