Question about overloading member function names

Discussion in 'C++' started by toadwarble, Jan 23, 2008.

  1. toadwarble

    toadwarble Guest

    I hit on a question today which seemed to be incorrect to me in the
    version of g++ I'm using (4.1.1)

    I have the following

    enum rectype_t {
    // Stuff....
    };

    class recordclass {
    // Stuff....
    };

    class base {
    // Stuff.....
    protected:
    void add_record(const recordclass &);
    };

    class derived1 : public base {
    // More stuff....
    public:
    void add_record(const rectype_t);
    };

    class derived2: public base {
    // More stuff...
    public:
    void add_record(const rectype_t);
    };

    However when I define the "add_record" functions for derived1 and
    derived2 thus:

    void derived1::add_record(const rectype_t rt)
    {
    recordclass rec(rt);
    // Fiddle with rec
    add_record(rec);
    }

    It chokes on the "add_record" which was meant to be a call to the base
    class version.

    It's OK if I put base:add_record(rec) or if I change the name of the
    base class function to "add_rec".

    Am I wrong to think that is unambiguous overloading or is g++ wrong?

    Thanks

    John Collins
    Xi Software Ltd
    toadwarble, Jan 23, 2008
    #1
    1. Advertising

  2. toadwarble

    Jim Langston Guest

    toadwarble wrote:
    > I hit on a question today which seemed to be incorrect to me in the
    > version of g++ I'm using (4.1.1)
    >
    > I have the following
    >
    > enum rectype_t {
    > // Stuff....
    > };
    >
    > class recordclass {
    > // Stuff....
    > };
    >
    > class base {
    > // Stuff.....
    > protected:
    > void add_record(const recordclass &);
    > };
    >
    > class derived1 : public base {
    > // More stuff....
    > public:
    > void add_record(const rectype_t);
    > };
    >
    > class derived2: public base {
    > // More stuff...
    > public:
    > void add_record(const rectype_t);
    > };
    >
    > However when I define the "add_record" functions for derived1 and
    > derived2 thus:
    >
    > void derived1::add_record(const rectype_t rt)
    > {
    > recordclass rec(rt);
    > // Fiddle with rec
    > add_record(rec);


    base::add_record(rec);

    > }
    >
    > It chokes on the "add_record" which was meant to be a call to the base
    > class version.
    >
    > It's OK if I put base:add_record(rec) or if I change the name of the
    > base class function to "add_rec".
    >
    > Am I wrong to think that is unambiguous overloading or is g++ wrong?
    >
    > Thanks
    >
    > John Collins
    > Xi Software Ltd




    --
    Jim Langston
    Jim Langston, Jan 23, 2008
    #2
    1. Advertising

  3. toadwarble

    toadwarble Guest

    On 23 Jan, 11:57, "Jim Langston" <> wrote:
    > toadwarble wrote:
    > > I hit on a question today which seemed to be incorrect to me in the
    > > version of g++ I'm using (4.1.1)

    >
    > > I have the following

    >
    > > enum rectype_t {
    > > // Stuff....
    > > };

    >
    > > class recordclass {
    > > // Stuff....
    > > };

    >
    > > class base {
    > > // Stuff.....
    > > protected:
    > > void add_record(const recordclass &);
    > > };

    >
    > > class derived1 : public base {
    > > // More stuff....
    > > public:
    > > void add_record(const rectype_t);
    > > };

    >
    > > class derived2: public base {
    > > // More stuff...
    > > public:
    > > void add_record(const rectype_t);
    > > };

    >
    > > However when I define the "add_record" functions for derived1 and
    > > derived2 thus:

    >
    > > void derived1::add_record(const rectype_t rt)
    > > {
    > > recordclass rec(rt);
    > > // Fiddle with rec
    > > add_record(rec);

    >
    > base::add_record(rec);
    >
    > > }

    >
    > > It chokes on the "add_record" which was meant to be a call to the base
    > > class version.

    >
    > > It's OK if I put base:add_record(rec) or if I change the name of the
    > > base class function to "add_rec".

    >
    > > Am I wrong to think that is unambiguous overloading or is g++ wrong?

    >
    > > Thanks

    >
    > > John Collins
    > > Xi Software Ltd

    >
    > --
    > Jim Langston
    >


    Sorry yes I spotted that after I posted it but I hoped people would
    get my drift.

    Can anyone help with the question?

    John Collins
    Xi Software Ltd
    toadwarble, Jan 23, 2008
    #3
  4. * toadwarble:
    > I hit on a question today which seemed to be incorrect to me in the
    > version of g++ I'm using (4.1.1)
    >
    > I have the following
    >
    > enum rectype_t {
    > // Stuff....
    > };
    >
    > class recordclass {
    > // Stuff....
    > };
    >
    > class base {
    > // Stuff.....
    > protected:
    > void add_record(const recordclass &);
    > };
    >
    > class derived1 : public base {
    > // More stuff....
    > public:
    > void add_record(const rectype_t);
    > };
    >
    > class derived2: public base {
    > // More stuff...
    > public:
    > void add_record(const rectype_t);
    > };
    >
    > However when I define the "add_record" functions for derived1 and
    > derived2 thus:
    >
    > void derived1::add_record(const rectype_t rt)
    > {
    > recordclass rec(rt);
    > // Fiddle with rec
    > add_record(rec);
    > }
    >
    > It chokes on the "add_record" which was meant to be a call to the base
    > class version.
    >
    > It's OK if I put base:add_record(rec) or if I change the name of the
    > base class function to "add_rec".
    >
    > Am I wrong to think that is unambiguous overloading or is g++ wrong?


    "add_record" in "derived1" hides the "add_record" in "base".

    You can either qualify the call with class name,

    base::add_record( rec );

    which can alternatively be done via "derived1" wrapper,

    void add_record( recordclass const& r ) { base::add_record( r ); }

    or call via a "base" reference or pointer,

    base& super = *this;
    super.add_record (rec );

    or bring the "base::add_record" overloads into "derived1" via a "using"
    declaration

    class derived1: public base
    {
    protected:
    using base::add_record;
    public:
    void add_record( rectype_t const );
    };

    The FAQ item discussing this is found at <url:
    http://www.parashift.com/c++-faq-lite/strange-inheritance.html#faq-23.9>.

    It doesn't discuss the reason why the language is this way. It's simply
    a more or less arbitrary choice of one evil instead of another. With
    the current rules, an introduction or removal of an overload in the base
    class won't affect which function is called in a derived class, except
    when you use the "using" solution where you say OK, fine by me.


    Cheers, & hth.,

    - Alf

    --
    A: Because it messes up the order in which people normally read text.
    Q: Why is it such a bad thing?
    A: Top-posting.
    Q: What is the most annoying thing on usenet and in e-mail?
    Alf P. Steinbach, Jan 23, 2008
    #4
  5. toadwarble

    Jerry Coffin Guest

    In article <5fee3c17-02f8-40b9-ac01-
    >, says...
    > I hit on a question today which seemed to be incorrect to me in the
    > version of g++ I'm using (4.1.1)
    >
    > I have the following


    [ ... derived class function hiding base class function ]

    > However when I define the "add_record" functions for derived1 and
    > derived2 thus:
    >
    > void derived1::add_record(const rectype_t rt)
    > {
    > recordclass rec(rt);
    > // Fiddle with rec
    > add_record(rec);
    > }
    >
    > It chokes on the "add_record" which was meant to be a call to the base
    > class version.


    The rule in C++ is that it looks backward through the "stack" of
    available scopes to find the name you've used. Once it finds a scope
    with that name, it looks for any overloads of that name in that scope.
    If one of them works, that's great. Otherwise, you have an error. Once
    it has found a scope where that name is visible, however, it NEVER
    attempts to search through more scopes to find more instances of the
    same name.

    Although it doesn't arise nearly as often in C, this rule is one that
    was inherited from C. For example, if I had something like this:

    double x;

    void f() {
    int x=1;

    x = 2.1;
    printf("%d\n", x);
    }

    Even though the type of the value being assigned is a double, and there
    is a double named x at global scope, the assignment is to the x that's
    local to f(), because as soon as the compiler finds that x, it quits
    looking for more.

    This is done so that each part of the program is as independent as
    possible. Without it, a change elsewhere in the program could change
    behavior of code that you think is fully tested and completely
    independent. For example, assume that in the code above, f() was
    originally written independently, and only later somebody added the
    global x. When they do so, the behavior of f() suddenly changes -- if
    the assignment is to the global, then there's no assignment to the
    local, and the function prints out 1 instead of 2.

    In C++ overloading allows us to have multiple "things" in the same scope
    with the same name. The rest of the rule remains the same though, and
    for the same basic reason: so something that is (and should be)
    independent remains independent unless it specifically requests
    otherwise.

    In this case, you can request otherwise on a case-by-case basis using a
    qualified name for the function. You can also do so on a more
    generalized basis with a using declaration:

    class derived : public base {
    using base::add_record;

    add_record(rect);
    };

    With code like this, any add_record in base is considered part of the
    overload set for uses of the name add_record in derived, so if one of
    them fits better than any version of add_record in derived, it'll be
    used. Keep in mind, however, that with this, you've bound your derived
    and base classes together a bit more closely -- changes in the base
    class can now affect the behavior of the derived class in ways that
    wouldn't otherwise be the case.

    > It's OK if I put base:add_record(rec) or if I change the name of the
    > base class function to "add_rec".
    >
    > Am I wrong to think that is unambiguous overloading or is g++ wrong?


    You're wrong and it's right. If it's any comfort, however, this question
    arises quite frequently, and most of the people who raise it are not
    ignorant newbies or anything like that either.

    --
    Later,
    Jerry.

    The universe is a figment of its own imagination.
    Jerry Coffin, Jan 23, 2008
    #5
  6. toadwarble

    toadwarble Guest

    On 23 Jan, 14:27, "Alf P. Steinbach" <> wrote:
    > * toadwarble:
    >
    >
    >
    > > I hit on a question today which seemed to be incorrect to me in the
    > > version of g++ I'm using (4.1.1)

    >
    > > I have the following

    >
    > > enum rectype_t {
    > > // Stuff....
    > > };

    >
    > > class recordclass {
    > > // Stuff....
    > > };

    >
    > > class base {
    > > // Stuff.....
    > > protected:
    > > void add_record(const recordclass &);
    > > };

    >
    > > class derived1 : public base {
    > > // More stuff....
    > > public:
    > > void add_record(const rectype_t);
    > > };

    >
    > > class derived2: public base {
    > > // More stuff...
    > > public:
    > > void add_record(const rectype_t);
    > > };

    >
    > > However when I define the "add_record" functions for derived1 and
    > > derived2 thus:

    >
    > > void derived1::add_record(const rectype_t rt)
    > > {
    > > recordclass rec(rt);
    > > // Fiddle with rec
    > > add_record(rec);
    > > }

    >
    > > It chokes on the "add_record" which was meant to be a call to the base
    > > class version.

    >
    > > It's OK if I put base:add_record(rec) or if I change the name of the
    > > base class function to "add_rec".

    >
    > > Am I wrong to think that is unambiguous overloading or is g++ wrong?

    >
    > "add_record" in "derived1" hides the "add_record" in "base".
    >
    > You can either qualify the call with class name,
    >
    > base::add_record( rec );
    >
    > which can alternatively be done via "derived1" wrapper,
    >
    > void add_record( recordclass const& r ) { base::add_record( r ); }
    >
    > or call via a "base" reference or pointer,
    >
    > base& super = *this;
    > super.add_record (rec );
    >
    > or bring the "base::add_record" overloads into "derived1" via a "using"
    > declaration
    >
    > class derived1: public base
    > {
    > protected:
    > using base::add_record;
    > public:
    > void add_record( rectype_t const );
    > };
    >
    > The FAQ item discussing this is found at <url:http://www.parashift.com/c++-faq-lite/strange-inheritance.html#faq-23.9>.
    >
    > It doesn't discuss the reason why the language is this way. It's simply
    > a more or less arbitrary choice of one evil instead of another. With
    > the current rules, an introduction or removal of an overload in the base
    > class won't affect which function is called in a derived class, except
    > when you use the "using" solution where you say OK, fine by me.
    >
    > Cheers, & hth.,
    >
    > - Alf
    >
    > --
    > A: Because it messes up the order in which people normally read text.
    > Q: Why is it such a bad thing?
    > A: Top-posting.
    > Q: What is the most annoying thing on usenet and in e-mail?


    Thanks. It seems my example is an easier case to deal with that the
    example on the URL you gave because the compiler chokes on my case
    whereas potentially in the illustrated case you could have your
    program build with some nasty unintended conversions, the wrong
    function called and mysterious bugs if warnings weren't turned on.

    (Yes I do build with -Wall and make it a policy never to have any
    warnings in he finished code).

    John Collins
    Xi Software Ltd
    toadwarble, Jan 23, 2008
    #6
    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. Ares Lagae
    Replies:
    8
    Views:
    435
    Ares Lagae
    Sep 24, 2004
  2. Iyer, Prasad C

    Overloading __init__ & Function overloading

    Iyer, Prasad C, Sep 30, 2005, in forum: Python
    Replies:
    3
    Views:
    6,391
    Fredrik Lundh
    Sep 30, 2005
  3. Replies:
    2
    Views:
    666
    Marcus Kwok
    Mar 14, 2007
  4. Hicham Mouline
    Replies:
    0
    Views:
    413
    Hicham Mouline
    Apr 23, 2009
  5. Hicham Mouline
    Replies:
    1
    Views:
    396
    Michael DOUBEZ
    Apr 24, 2009
Loading...

Share This Page