By the C++ rules a name declared in the derived class hides that name in the
parent. That is quite logical for simple items like data members. But IMO
that's not the case for functions. Say,
struct base {
    int f();
    int f(int,int);
}
struct derived : public base {
    int f()
};
// WARNING: derived::f() hides name base::f(int,int)
derived d;
f.f();          // ok.
f.f(1,2);       // error;
f:base::f(1,2); // now ok.
I think the overloaded variants of a function is well distinguishable from
other forms, defined in place or inherited. Redefininf f() and inheriting
parent's f(int,int) without additional problems would be mnore intuitive, and
make no more work to the compiler.
Another question: is it a new behavior in C++?  MFC writers didn't take it
into account, as CSyncObject use similar inherintace:
virtual Lock() = 0;
virtual Lock(something);  // this is defined in CSyncObject
And inherited classes like CMutex, etc do not define but the first.
And as CSyncObject is an abstract class it's not really clear the benefit of
definig the second Lock there.
Paul
... #@$ffwe99fjaljk ... Hey! Get the cat off the keyboard!
--- OS/2 Warp
---------------