This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

c++/3585: wrong function overload resolution?

>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
>Originator:     Ewgenij Gawrilow
>Release:        3.0
Sun UltraSPARC, Solaris 8
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!



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]