Re: Inherit, same named methods

On 2009-11-04, Michael D. Berger <m_d_berger_1900@yahoo.com> wrote:


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++.


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.