Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > function overloading question

Reply
Thread Tools

function overloading question

 
 
Steve Pope
Guest
Posts: n/a
 
      08-06-2006
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
 
Reply With Quote
 
 
 
 
Thomas J. Gritzan
Guest
Posts: n/a
 
      08-06-2006
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
 
Reply With Quote
 
 
 
 
Steve Pope
Guest
Posts: n/a
 
      08-06-2006
Thomas J. Gritzan <(E-Mail Removed)> wrote:

>return ::foo(a);


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

Steve
 
Reply With Quote
 
Alf P. Steinbach
Guest
Posts: n/a
 
      08-06-2006
* 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?
 
Reply With Quote
 
Steve Pope
Guest
Posts: n/a
 
      08-06-2006
Alf P. Steinbach <(E-Mail Removed)> 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.
 
Reply With Quote
 
Alf P. Steinbach
Guest
Posts: n/a
 
      08-06-2006
* Steve Pope:
> Alf P. Steinbach <(E-Mail Removed)> 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?
 
Reply With Quote
 
Ron Natalie
Guest
Posts: n/a
 
      08-07-2006
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.
 
Reply With Quote
 
Pete Becker
Guest
Posts: n/a
 
      08-07-2006
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.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
RE: Overloading __init__ & Function overloading Iyer, Prasad C Python 4 09-30-2005 08:01 PM
Re: Overloading __init__ & Function overloading Fredrik Lundh Python 0 09-30-2005 03:59 PM
Overloading __init__ & Function overloading Iyer, Prasad C Python 3 09-30-2005 02:17 PM
Re: Overloading __init__ & Function overloading Steve Holden Python 0 09-30-2005 01:58 PM
Re: Overloading __init__ & Function overloading Fredrik Lundh Python 0 09-30-2005 01:53 PM



Advertisments