On Thu, Aug 07, 2003 at 05:24:07AM -0400, Ben Cronin wrote:
>
> I'm curious why gcc reports the call to print() below as an
> ambiguous reference. Is this ambiguous according to the C++ standard?
Indeed, it is defined eg. in Stroustrup's C++ the Language 15.2.2 that
ambiguities between functions of different base classes won't be resolved
by their argument types.
It protects the programmer from bad surprises. Often, functions with
the same name inherited from different base classes don't serve the
same purpose. Depending on how complex your class hierarchy is, you
might not know what kind of functions with the name "foo" are defined
down your hierarchy tree and you think you call B::foo(int) but are
really calling C::D::X::foo(unsigned int) because your argument to
that function happens to be an unsigned int. This being just a dumb
example I suppose it could cause you quite a headache figuring this
mess out. So, I think it's better to be forced directly qualifying the
function one wants/intends to use.
(snip)
> --------
> #include <cstdio>
> using namespace std;
>
> struct B
> {
> struct T { } t;
> void print(T&) { printf("B\n"); }
> };
> struct C
> {
> struct S { } s;
> void print(S&) { printf("C\n"); }
> };
>
> struct A : public B, public C
> {
> };
>
> int main(int argc, char** argv)
> {
> A a;
> a.print(a.t);
> return 0;
> }
> --------
>
> GCC prints the error:
>
> test.cpp: In function `int main(int, char**)':
> test.cpp:22: request for member `print' is ambiguous
> test.cpp:12: candidates are: void C::print(C::S&)
> test.cpp:7: void B::print(B::T&)
>
> Also, it was pointed out to me that adding "using A::print; using
> B::print;" in the definition of A unambiguates the reference. But why
> is that necessary?
--
Claudio Bley ASCII ribbon campaign (")
Debian GNU/Linux user - against HTML email X
http://www.cs.uni-magdeburg.de/~bley/ & vCards / \
