Re: Inherit, same named methods

On 2009-11-04, Michael D. Berger <> wrote:
> Given:
>
> class A : protected B
> {
> ...
> }
>
> Can can the two classes have inline,
> non-virtual methods with the same name?

In a sense yes, in a sense no.

Suppose B has one or more member functions called foo. (There may be more
than one due to overloading).

If A also introduces a member called foo, then this identifier will
shadow all of those functions in B.

So, as you correctly suspect, there is in fact a kind of conflict between same
names in a base and derived class, which is resolved by shadowing: the
presence of a name in the derived class suppresses the inheritance of that
/name/ from the base class into the scope of the derived class. (But it does
not suppress the inheritance of the /things/ which are named, just the names!
C++ has two kinds of inheritance going on: inheritance of class-scoped
identifiers from one class to another, and inheritance of actual entities like
member functions, data members, and member types).

So for instance if you have

int B::foo(int);
int B::foo(double);

and inside A you have

int A::foo(unsigned long);

then when you call ``a.foo(3)'' on an A object a, only A::foo(unsigned long) is
considered by overload resolution. It's as if the two B::foo functions did not
exist; the expression simply does not see them.

But if A did not have a member called foo, then A::foo will nicely refer to the
set of overloaded functions from B. I.e. the B::foo name is inherited into A,
becoming visible in A's class scope.

In either case, the B functions are reachable via scope resolution:
a.B::foo(...).

You can promote the B functions into A with using directives, so that they are
considered together with A::foo(unsigned int) as candidates for overload
resolution:

class A : public B {
public:
using B::foo; // This is as if A itself now defined those functions.
int foo(unsigned long);
};

You don't get to cherry-pick the foo's from B: using B::foo gets
you all of them (you're importing the name, not the functions,
which you have already inherited!)

There can't be a clash, either. If one of the B::foo function is
foo(unsigned long), you're out of luck. Or if B has a foo name which
refers to something other than a function, you're also out of luck: because
then you're asking to have an A::foo which refers to the function
int A::foo(unsigned long), as well as some non-function entity also,
which is a form of overloading not supported in C++.

> What if the inheritance is public?

These public, private and protected specifiers determine access control.
Access control does not determine what is visible and what is inherited,
but what is accessible.

Access control is a way of specifying that if when some visible identifiers are
referenced from certain scopes, then a diagnostic message is required from the
compiler. It's like a glass case: you can see something, but you can't
touch it.

Kaz Kylheku