http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11750
Balakrishnan B <balakrishnan.erode at gmail dot com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |balakrishnan.erode at gmail | |dot com --- Comment #6 from Balakrishnan B <balakrishnan.erode at gmail dot com> 2011-01-12 16:57:07 UTC --- (In reply to comment #0) > Paragraph 10.3/2 in the C++ standard [ISO/IEC 14882:1998] provides 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 using-declaration > } > > </quote> > > When a similar program is compiled using G++ 3.3, the method call 'c.f()' in > function foo() incorrectly invokes A::f and not B::f as specified in the > 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(); // ERROR - Incorrectly invokes A::f > c.C::f(); // OK - Invokes A::f > } > </code> > > <build> > $ g++ main.cpp > > $ ldd a.out > libstdc++.so.5 => > /usr/local/gcc/3.3/lib/gcc-lib/i686-pc-linux-gnu/3.3/libstdc++.so.5 > (0x40017000) > libm.so.6 => /lib/tls/libm.so.6 (0x400e4000) > libgcc_s.so.1 => > /usr/local/gcc/3.3/lib/gcc-lib/i686-pc-linux-gnu/3.3/libgcc_s.so.1 > (0x40106000) > libc.so.6 => /lib/tls/libc.so.6 (0x42000000) > /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) > </build> > > <output> > $ ./a.out > A::f() > A::f() > </output> > > </example> Im using g++ 4.4.5 With the same example with my main function as below, int main() { C c; c.f() // Calls A::f C* pc = &c; pc->f() // Calls B::f } With the same object when accessed directly produces different results and when accessed using a pointer of same type produces a different result. Even if gcc violates standard, there has to be some proper explanation.