Derived class function masks base class function

Discussion in 'C++' started by Lionel B, Feb 5, 2009.

  1. Lionel B

    Lionel B Guest

    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
    Lionel B, Feb 5, 2009
    #1
    1. Advertising

  2. Lionel B

    Lionel B Guest

    On Thu, 05 Feb 2009 14:00:54 +0000, Lionel B wrote:

    > 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?

    --
    Lionel B
    Lionel B, Feb 5, 2009
    #2
    1. Advertising

  3. On Feb 5, 9:17 am, Lionel B <> wrote:
    > On Thu, 05 Feb 2009 14:00:54 +0000, Lionel B wrote:
    > > 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?
    >
    > --
    > Lionel B


    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.
    puzzlecracker, Feb 5, 2009
    #3
  4. Lionel B

    Lionel B Guest

    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
    Lionel B, Feb 5, 2009
    #4
  5. Lionel B

    Lionel B Guest

    On Thu, 05 Feb 2009 09:22:58 -0500, Victor Bazarov wrote:

    > Lionel B wrote:
    >> On Thu, 05 Feb 2009 14:00:54 +0000, Lionel B wrote:


    [...]

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

    --
    Lionel B
    Lionel B, Feb 5, 2009
    #5
  6. Lionel B

    Guest

    On Feb 5, 2:00 pm, Lionel B <> wrote:
    > 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

    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
    , Feb 5, 2009
    #6
  7. Lionel B

    Guest

    On Feb 5, 2:17 pm, Lionel B <> wrote:
    > On Thu, 05 Feb 2009 14:00:54 +0000, Lionel B wrote:
    > > 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?
    >
    > --
    > Lionel B


    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
    , Feb 5, 2009
    #7
  8. On Feb 5, 9:39 am, Lionel B <> wrote:
    > 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


    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.
    puzzlecracker, Feb 5, 2009
    #8
  9. Lionel B

    James Kanze Guest

    On Feb 5, 3:17 pm, Lionel B <> wrote:
    > On Thu, 05 Feb 2009 14:00:54 +0000, Lionel B wrote:


    > > 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?


    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?

    --
    James Kanze
    James Kanze, Feb 5, 2009
    #9
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Replies:
    4
    Views:
    404
    Alf P. Steinbach
    May 23, 2007
  2. Replies:
    1
    Views:
    393
    myork
    May 23, 2007
  3. Replies:
    1
    Views:
    385
    Victor Bazarov
    May 23, 2007
  4. Replies:
    2
    Views:
    706
  5. George2
    Replies:
    0
    Views:
    348
    George2
    Mar 17, 2008
Loading...

Share This Page