function overloading question

Discussion in 'C++' started by Steve Pope, Aug 6, 2006.

  1. Steve Pope

    Steve Pope Guest

    Is there a reason I am unable to overload foo()
    in the following code, which does not compile ("no
    matching function")?

    int foo(int a) {
    return(a);
    }

    struct goo {
    int a;
    int foo();
    };

    int goo::foo() {
    return(foo(this->a));
    }

    Thanks,

    Steve
     
    Steve Pope, Aug 6, 2006
    #1
    1. Advertising

  2. Steve Pope schrieb:
    > Is there a reason I am unable to overload foo()
    > in the following code, which does not compile ("no
    > matching function")?
    >
    > int foo(int a) {
    > return(a);
    > }
    >
    > struct goo {
    > int a;
    > int foo();
    > };
    >
    > int goo::foo() {
    > return(foo(this->a));


    return ::foo(a);

    > }


    --
    Thomas
     
    Thomas J. Gritzan, Aug 7, 2006
    #2
    1. Advertising

  3. Steve Pope

    Steve Pope Guest

    Thomas J. Gritzan <> wrote:

    >return ::foo(a);


    Yes, that makes it work, but I'm still unclear on why
    it's necessary.

    Steve
     
    Steve Pope, Aug 7, 2006
    #3
  4. * Steve Pope:
    > Is there a reason I am unable to overload foo()
    > in the following code, which does not compile ("no
    > matching function")?
    >
    > int foo(int a) {
    > return(a);
    > }
    >
    > struct goo {
    > int a;
    > int foo();
    > };
    >
    > int goo::foo() {
    > return(foo(this->a));
    > }


    As far as this group is concerned, because goo::foo hides the global foo
    (see note*). The global foo is not considered. Many people find the
    hiding behavior counter-intuitive, although it does tend to minimize
    surprises; for the reasons why the language is like that I suggest
    asking in [comp.std.c++].

    *) §3.4.1/1 "name lookup ends as soon as a declaration is found for the
    name"
    --
    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, Aug 7, 2006
    #4
  5. Steve Pope

    Steve Pope Guest

    Alf P. Steinbach <> wrote:

    > As far as this group is concerned, because goo::foo hides
    > the global foo (see note*). The global foo is not considered.
    > Many people find the hiding behavior counter-intuitive, although
    > it does tend to minimize surprises; for the reasons why the
    > language is like that I suggest asking in [comp.std.c++].


    > *) §3.4.1/1 "name lookup ends as soon as a declaration is found
    > for the name"


    Thanks. So, the first namespace in which it finds a declaration
    is the only namespace it will look for a function with the
    right prototype? That does seem a bit counterintuitive.

    S.
     
    Steve Pope, Aug 7, 2006
    #5
  6. * Steve Pope:
    > Alf P. Steinbach <> wrote:
    >
    >> As far as this group is concerned, because goo::foo hides
    >> the global foo (see note*). The global foo is not considered.
    >> Many people find the hiding behavior counter-intuitive, although
    >> it does tend to minimize surprises; for the reasons why the
    >> language is like that I suggest asking in [comp.std.c++].

    >
    >> *) §3.4.1/1 "name lookup ends as soon as a declaration is found
    >> for the name"

    >
    > Thanks. So, the first namespace in which it finds a declaration
    > is the only namespace it will look for a function with the
    > right prototype?


    No, but for a name used in the definition of a member function, if a
    declaration of the name is found in the class, then that's it.


    > That does seem a bit counterintuitive.


    Names are looked up first, then overload resolution is applied for
    functions, then access rights are checked.

    The counter-intuitiveness has more to do with the way it doesn't work
    the way people expect, like, a typedef being considered a best match for
    what you think of as a function call (names are looked up before
    applying knowledge of what they stand for), or a function introduced in
    a derived class hiding function overloads with same name in base class,
    or the compiler seemingly out of malice insisting on matching a name to
    some private declaration in a base class and then complaining.

    It's horribly complicated, which is another way of saying that I or just
    about anyone couldn't give you the complete effective rules but we're
    good at limiting ourselves to using only the subset of the language
    that's relatively easy to understand, and rationalizing what compilers
    do by finding seemingly relevant language in the standard... ;-)

    --
    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, Aug 7, 2006
    #6
  7. Steve Pope

    Ron Natalie Guest

    Steve Pope wrote:
    > Is there a reason I am unable to overload foo()
    > in the following code, which does not compile ("no
    > matching function")?
    >

    Name lookup occurs before overloading occurs.
     
    Ron Natalie, Aug 7, 2006
    #7
  8. Steve Pope

    Pete Becker Guest

    Steve Pope wrote:
    >
    > Thanks. So, the first namespace in which it finds a declaration
    > is the only namespace it will look for a function with the
    > right prototype?
    >


    Overloading only applies to names that are defined in the same scope.
     
    Pete Becker, Aug 7, 2006
    #8
    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. Iyer, Prasad C

    Overloading __init__ & Function overloading

    Iyer, Prasad C, Sep 30, 2005, in forum: Python
    Replies:
    3
    Views:
    6,413
    Fredrik Lundh
    Sep 30, 2005
  2. Fredrik Lundh
    Replies:
    0
    Views:
    451
    Fredrik Lundh
    Sep 30, 2005
  3. Steve Holden
    Replies:
    0
    Views:
    431
    Steve Holden
    Sep 30, 2005
  4. Iyer, Prasad C
    Replies:
    4
    Views:
    581
    John J. Lee
    Sep 30, 2005
  5. Fredrik Lundh
    Replies:
    0
    Views:
    402
    Fredrik Lundh
    Sep 30, 2005
Loading...

Share This Page