public inbox for gcc-prs@sourceware.org
help / color / mirror / Atom feed
* Re: c++/3585: wrong function overload resolution?
@ 2001-07-06 6:51 gdr
0 siblings, 0 replies; 4+ messages in thread
From: gdr @ 2001-07-06 6:51 UTC (permalink / raw)
To: gawrilow, gcc-bugs, gcc-prs, gdr, nobody
Synopsis: wrong function overload resolution?
Responsible-Changed-From-To: unassigned->gdr
Responsible-Changed-By: gdr
Responsible-Changed-When: Fri Jul 6 06:51:22 2001
Responsible-Changed-Why:
Analysed.
State-Changed-From-To: open->closed
State-Changed-By: gdr
State-Changed-When: Fri Jul 6 06:51:22 2001
State-Changed-Why:
Not a bug.
http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=3585&database=gcc
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: c++/3585: wrong function overload resolution?
@ 2001-07-06 9:56 Martin Sebor
0 siblings, 0 replies; 4+ messages in thread
From: Martin Sebor @ 2001-07-06 9:56 UTC (permalink / raw)
To: gdr; +Cc: gcc-prs
The following reply was made to PR c++/3585; it has been noted by GNATS.
From: Martin Sebor <sebor@roguewave.com>
To: gcc-gnats@gcc.gnu.org
Cc:
Subject: Re: c++/3585: wrong function overload resolution?
Date: Fri, 06 Jul 2001 10:53:13 -0600
gawrilow@math.tu-berlin.de wrote:
>
> >Number: 3585
> >Category: c++
> >Synopsis: wrong function overload resolution?
...
> >Description:
> Let's consider the following fragment:
>
> void f(int& x) { } // #1
>
> void f(int x) { } // #2
>
> int temp() { return 0; }
>
> int main() {
> int var=0;
> f(var); // should resolve to #1
> f(temp()); // resolves to #2
> }
>
> The gcc rejects f(var) as ambiguous reasoning that #1 and #2
> were equally good. IMHO, resolving to #2 includes an
> lvalue-to-rvalue conversion, where #1 incurs an identity
> conversion, thus being better. Am I missing something?
I think so: Reference Binding is considered the Identity conversion
(see 13.3.3.1.4, p1).
>
> The things become yet prettier as we move to templates.
> Let's change the definitions of f's to the following:
>
> template <class T> void f(T& x) { } // #1
> template <class T> void f(T x) { } // #2
>
> gcc 3.0 still considers this ambiguous, while 2.95 has
> chosen #1 for f(var) without any complains.
The call to f (var) is also ambiguous here. Argument deduction
finds [T = int] in both cases and you're left with the same as
above.
>
> Thus the final questions: who understands the overload
> resolution rules better: gcc 3.0, gcc 2.95,
> me (obviously not!), or somebody else?
I'd say 3.0 is correct here and 2.95 is in error. Most other
compilers agree.
>
> How could I otherwise distinct between rvalue and lvalue
> arguments to an overloaded function, without using
> f(const T&) ?
Here's how you can tell an lvalue from an rvalue:
bool is_lvalue (...) { return false; }
template <class T>
bool is_lvalue (T&) { return true; }
Regards
Martin
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: c++/3585: wrong function overload resolution?
@ 2001-07-06 6:56 Gabriel Dos Reis
0 siblings, 0 replies; 4+ messages in thread
From: Gabriel Dos Reis @ 2001-07-06 6:56 UTC (permalink / raw)
To: gdr; +Cc: gcc-prs
The following reply was made to PR c++/3585; it has been noted by GNATS.
From: Gabriel Dos Reis <Gabriel.Dos-Reis@cmla.ens-cachan.fr>
To: gawrilow@math.tu-berlin.de
Cc: gcc-gnats@gcc.gnu.org
Subject: Re: c++/3585: wrong function overload resolution?
Date: 06 Jul 2001 15:49:45 +0200
gawrilow@math.tu-berlin.de writes:
| >Number: 3585
| >Category: c++
| >Synopsis: wrong function overload resolution?
| >Confidential: no
| >Severity: serious
| >Priority: medium
| >Responsible: unassigned
| >State: open
| >Class: rejects-legal
| >Submitter-Id: net
| >Arrival-Date: Fri Jul 06 04:06:01 PDT 2001
| >Closed-Date:
| >Last-Modified:
| >Originator: Ewgenij Gawrilow
| >Release: 3.0
| >Organization:
| >Environment:
| Sun UltraSPARC, Solaris 8
| >Description:
| Let's consider the following fragment:
|
| void f(int& x) { } // #1
|
| void f(int x) { } // #2
Nobody should be writing that :-)
| int temp() { return 0; }
|
| int main() {
| int var=0;
| f(var); // should resolve to #1
On what basis?
| f(temp()); // resolves to #2
| }
|
| The gcc rejects f(var) as ambiguous reasoning that #1 and #2
| were equally good.
GCC is right in doing so.
| IMHO, resolving to #2 includes an
| lvalue-to-rvalue conversion, where #1 incurs an identity
| conversion, thus being better. Am I missing something?
identity and lvalue-to-rvalue conversion both have Exact Match rank.
See Table 9.
| Thus the final questions: who understands the overload
| resolution rules better: gcc 3.0, gcc 2.95,
GCC-3.0.
| How could I otherwise distinct between rvalue and lvalue
| arguments to an overloaded function, without using
| f(const T&) ?
You cannot because both lvalue-transformation and identity
transformation have Exact Match rank.
-- Gaby
^ permalink raw reply [flat|nested] 4+ messages in thread
* c++/3585: wrong function overload resolution?
@ 2001-07-06 4:06 gawrilow
0 siblings, 0 replies; 4+ messages in thread
From: gawrilow @ 2001-07-06 4:06 UTC (permalink / raw)
To: gcc-gnats
>Number: 3585
>Category: c++
>Synopsis: wrong function overload resolution?
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: unassigned
>State: open
>Class: rejects-legal
>Submitter-Id: net
>Arrival-Date: Fri Jul 06 04:06:01 PDT 2001
>Closed-Date:
>Last-Modified:
>Originator: Ewgenij Gawrilow
>Release: 3.0
>Organization:
>Environment:
Sun UltraSPARC, Solaris 8
>Description:
Let's consider the following fragment:
void f(int& x) { } // #1
void f(int x) { } // #2
int temp() { return 0; }
int main() {
int var=0;
f(var); // should resolve to #1
f(temp()); // resolves to #2
}
The gcc rejects f(var) as ambiguous reasoning that #1 and #2
were equally good. IMHO, resolving to #2 includes an
lvalue-to-rvalue conversion, where #1 incurs an identity
conversion, thus being better. Am I missing something?
The things become yet prettier as we move to templates.
Let's change the definitions of f's to the following:
template <class T> void f(T& x) { } // #1
template <class T> void f(T x) { } // #2
gcc 3.0 still considers this ambiguous, while 2.95 has
chosen #1 for f(var) without any complains.
Thus the final questions: who understands the overload
resolution rules better: gcc 3.0, gcc 2.95,
me (obviously not!), or somebody else?
How could I otherwise distinct between rvalue and lvalue
arguments to an overloaded function, without using
f(const T&) ?
Thanks in advance for any hint!
>How-To-Repeat:
>Fix:
>Release-Note:
>Audit-Trail:
>Unformatted:
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2001-07-06 9:56 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2001-07-06 6:51 c++/3585: wrong function overload resolution? gdr
-- strict thread matches above, loose matches on Subject: below --
2001-07-06 9:56 Martin Sebor
2001-07-06 6:56 Gabriel Dos Reis
2001-07-06 4:06 gawrilow
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).