function overloading question

[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));
}

Thanks,

Steve

 

[Thomas J. Gritzan]

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);

 

[Steve Pope]

return ::foo(a);

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

Steve

 

[Alf P. Steinbach]

* 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"

 

[Steve Pope]

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.

 

[Alf P. Steinbach]

* Steve Pope:

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

 

[Ron Natalie]

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.

 

[Pete Becker]

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.