Derived class function masks base class function

[Lionel B]

Hi,

I am vexed by the following behaviour:

struct Base
{
int i;

void func(int i_)
{
i = i_;
}
};

struct Derived : Base
{
int j;

void func(int i_, int j_)
{
i = i_;
j = j_;
}
};

int main()
{
Derived x;

x.func(3);
}

My compiler tells me:

scratch.cpp:26: error: no matching function for call to ‘Derived::func(int)’
scratch.cpp:15: note: candidates are: void Derived::func(int, int)

If the definition of Derived::func(int, int) is commented out the code
compiles ok.

What puzzles me is that the signatures of Base::func(int) and
Derived::func(int, int) are different; so if the compiler fails to find a
match for Derived::func(int), why does it not match Base::func(int), as
it will if Derived::func(int, int) is not present?

 

[Lionel B]

Hi,

I am vexed by the following behaviour:

struct Base
{
int i;

void func(int i_)
{
i = i_;
}
};

struct Derived : Base
{
int j;

void func(int i_, int j_)
{
i = i_;
j = j_;
}
};

int main()
{
Derived x;

x.func(3);
}

My compiler tells me:

scratch.cpp:26: error: no matching function for call to
‘Derived::func(int)’ scratch.cpp:15: note: candidates are: void
Derived::func(int, int)

If the definition of Derived::func(int, int) is commented out the code
compiles ok.

What puzzles me is that the signatures of Base::func(int) and
Derived::func(int, int) are different; so if the compiler fails to find
a match for Derived::func(int), why does it not match Base::func(int),
as it will if Derived::func(int, int) is not present?

Ok, it's (almost?) FAQ 23.9, it seems. Can be resolved by:

using Base::func;

in the Derived declaration.

Anyone care to explain the reasoning behind this feature?

 

[puzzlecracker]

Ok, it's (almost?) FAQ 23.9, it seems. Can be resolved by:

  using Base::func;

in the Derived declaration.

Anyone care to explain the reasoning behind this feature?

Lion, first of all, the issue here is name hiding. I think it was
designed to help programmers to avoid a hard tracking errors.

Second of all, steer clear of this russkiy Victor, who is the most
presumptuous and obnoxious person on this newsgroup.

 

[Lionel B]

On Thu, 05 Feb 2009 06:26:29 -0800, puzzlecracker wrote:

[...]

Second of all, steer clear of this russkiy Victor, who is the most
presumptuous and obnoxious person on this newsgroup.

Whatever you think of Victor (and I've found him knowledgeable and
helpful in the past, if somewhat terse), his (supposed) nationality is
irrelevant and mentioning it in this context implies a racist attitude on
your part.

Now that *is* obnoxious.

<plonk>

 

[Lionel B]

[...]

Anyone care to explain the reasoning behind this feature?

Read up on "name hiding". And I am not sure what *reasoning* you're
looking for, honestly, but you probably will find something to think
about if you search any material on "c++ name hiding" on the 'net.

Thanks, I shall read up more on name hiding. I guess what perplexed me in
this case is my understanding that functions in C++ are generally
distinguishable by signature.

As for the rationale, I can appreciate that having, say, a derived func
(int) *not* hiding a base func(double) - in conjunction with implicit
conversion - could cause mayhem...

 

[gob00st]

Hi,

I am vexed by the following behaviour:

struct Base
{
  int i;

  void func(int i_)
  {
    i = i_;
  }

};

struct Derived : Base
{
  int j;

  void func(int i_, int j_)
  {
    i = i_;
    j = j_;
  }

};

int main()
{
  Derived x;

  x.func(3);

}

My compiler tells me:

scratch.cpp:26: error: no matching function for call to ‘Derived::func(int)’
scratch.cpp:15: note: candidates are: void Derived::func(int, int)

If the definition of Derived::func(int, int) is commented out the code
compiles ok.

What puzzles me is that the signatures of Base::func(int) and
Derived::func(int, int) are different; so if the compiler fails to find a
match for Derived::func(int), why does it not match Base::func(int), as
it will if Derived::func(int, int) is not present?

Name hiding is correct answer:
A member function named f in a class A will hide all other members
named f in the base classes of A, regardless of return types or
arguments.
If you interested in more reading , you can check chapter 10.2 of ISO C
++ Standard 2003 version.
Gob00st

 

[gob00st]

Ok, it's (almost?) FAQ 23.9, it seems. Can be resolved by:

  using Base::func;

in the Derived declaration.

Anyone care to explain the reasoning behind this feature?

C++ introduces the using-directives to inject extra name(e.g the name
being hidden in the base class bcos of name hiding rule) into scope.
Gob00st

 

[puzzlecracker]

On Thu, 05 Feb 2009 06:26:29 -0800, puzzlecracker wrote:

[...]

Second of all, steer clear of this russkiy Victor, who  is the most
presumptuous and obnoxious person on this newsgroup.

Whatever you think of Victor (and I've found him knowledgeable and
helpful in the past, if somewhat terse), his (supposed) nationality is
irrelevant and mentioning it in this context implies a racist attitude on
your part.

Now that *is* obnoxious.

<plonk>

I don't question his knowledge nor nationality (as I am originally
from Russia as well). However, his mannerism and the condescending
nature of his responses is rather demeaning to people. He has HIS
expectation of the quality and form of question that people should
post, and anything short of that, deserves a verbal spanking.

 

[James Kanze]

Ok, it's (almost?) FAQ 23.9, it seems. Can be resolved by:

using Base::func;

in the Derived declaration.

Anyone care to explain the reasoning behind this feature?

One reason (probably not the only one), is so that adding a
(possibly private) function to the base class cannot break the
code in the derived class. In other words, given:

class Base
{
// ...
} ;

class Derived : public Base
{
public:
void f( int i ) ;
void g() { f( 'a' ) ; }
} ;

as written, g() calls Derived::f( int ). And this will continue
to be true even if Base evolves to have an f( char ) member.

More generally, in all other contexts of unqualified name
lookup, the compiler stops looking when it finds a scope with
the name. Why should function names be different?