virtual methods, virtual bases bug<?> in G++ 3.3

[Jim Fischer]

Paragraph 10.3/2 in the C++ standard [ISO/IEC 14882:1998] has the
following code example:

<quote>
struct A {
virtual void f();
};
struct B : virtual A {
virtual void f();
};

struct C : B , virtual A {
using A::f;
};
void foo() {
C c;
c.f(); // calls B::f, the final overrider
c.C::f(); // calls A::f because of the usingdeclaration
}
</quote>

It seems a little odd (to me) that the method call 'c.f()' in function
foo() should invoke B::f. I thought it would invoke A::f due to the
using declaration 'using A::f;' in class C's declaration block. And in
fact, when I use G++ 3.3 to build the code sample shown below, the
method call 'c.f()' invokes A::f (which is what I expected), and not
B::f as stated in the C++ standard.

<example>

<code main.cpp>
#include <iostream>

struct A {
virtual void f() { std::cout << "A::f()\n"; }
};
struct B : virtual A {
virtual void f() { std::cout << "B::f()\n"; }
};
struct C : B, virtual A {
using A::f;
};

int main()
{
C c;
c.f(); // g++ 3.3 invokes A::f, not B::f
c.C::f();
}
</code main.cpp>

<build>
g++ main.cpp
</build>

<output>
A::f()
A::f()
</output>

</example>

FWIW, I looked around on the "JTC1/SC22/WG21 - C++" web site,

http://anubis.dkuug.dk/jtc1/sc22/wg21/

but I didn't find anything about this particular issue (e.g., in the
"Core Language Issues" pages). So I'd like some verification that c.f()
is indeed supposed to invoke B::f, as stated in the standard, and not A::f.

 

[Janusz Szpilewski]

void foo() {
C c;
c.f(); // calls B::f, the final overrider
c.C::f(); // calls A::f because of the usingdeclaration
}
</quote>

It seems a little odd (to me) that the method call 'c.f()' in function
foo() should invoke B::f. I thought it would invoke A::f due to the
using declaration 'using A::f;' in class C's declaration block. And in
fact, when I use G++ 3.3 to build the code sample shown below, the
method call 'c.f()' invokes A::f (which is what I expected), and not
B::f as stated in the C++ standard.

I think there is some rational explanation.

If the member function name is not (scope) qualified (like c.f()) then
the final overrider is called.

If it is, the name used in the qualified scope is chosen. As shows the
example member function name does not have to be overridden, it may be
referred by using directive. But in this case such a name is not
considered when looking for overriders so the last overrider down in the
hierarchy is chosen.

Btw, Borland C++ compiles the example according to the standard.

Regards,
Janusz

 

[Victor Bazarov]

Paragraph 10.3/2 in the C++ standard [ISO/IEC 14882:1998] has the
following code example:

<quote>
struct A {
virtual void f();
};
struct B : virtual A {
virtual void f();
};

struct C : B , virtual A {
using A::f;
};
void foo() {
C c;
c.f(); // calls B::f, the final overrider
c.C::f(); // calls A::f because of the usingdeclaration
}
</quote>

It seems a little odd (to me) that the method call 'c.f()' in function
foo() should invoke B::f. I thought it would invoke A::f due to the
using declaration 'using A::f;' in class C's declaration block. And in
fact, when I use G++ 3.3 to build the code sample shown below, the
method call 'c.f()' invokes A::f (which is what I expected), and not
B::f as stated in the C++ standard.

Did you actually read the paragraph preceding the example? Name
lookup for the call

c.f();

ignores names introduced by using declarations. That is, C::f is
ignored, and B::f is found.

So, G++ v3.3 is buggy. Name resolution is a tricky thing, not all
of the implementations do it right.

Victor

 

[Jim Fischer]

I think there is some rational explanation.

If the member function name is not (scope) qualified (like c.f()) then
the final overrider is called.

If it is, the name used in the qualified scope is chosen. As shows the
example member function name does not have to be overridden, it may be
referred by using directive. But in this case such a name is not
considered when looking for overriders so the last overrider down in the
hierarchy is chosen.

Btw, Borland C++ compiles the example according to the standard.

Thanks for the reply. I understand the meaning of paragraph 10.3/2
(although the description given in the standard is different from what I
originally expected, but of course that's irrelevant). I was basically
looking for confirmation that 10.3/2 still applies -- that there have
not been any official changes to that particular paragraph -- before
submitting a bug report to the GNU g++ maintainers. FWIW, this afternoon
I submitted a G++ bugzilla report on this issue.