Jerry Leichter wrote:

> HP's aCC (missing the absolute latest set of patches, but I don't recall
> seeing any indication of a patch in this area) compiles the whole thing
> with no complaints.  The result produces the following output:

First let write down the viable functions:

> 26: u(i)-> u(int&)

Candidates are: u(int&), u(const int&)
But u(const int&) requires a qualification conversion (at least
I think it's called qualification conversion), so this ok.

> 27: u(ci)-> u(const int&)

Candidates are: u(const int&)
ok

> 28: u(1)-> u(const int&)

Candidates are: u(const int&)
ok

> 32: v(i)-> v(const int&)
> 33: v(ci)-> v(const int&)
> 34: v(1)-> v(int)

For the above cases:
Candidates are: v(int), v(const int&)
They aren't comparable, so these calls are ambiguous.

> Lines 32 and 33 make sense if you assume a preference, in overloading,
> for a const ref T over a T.  This is a reasonable thing to do -

I disagree.

> certainly for class types - but I can't seem to find language to justify
> it.  Line 34, on the other hand, is a puzzle:  How does it differ from
> line 33?

1 is an rvalue of type int, ci is a lvalue of type const int

(Note that g++ makes all these three cases ambiguous. :-)

> Can anyone explicate?

The rules were badly broken and changed recently.

--

Valentin Bonnard


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

I've tried reading the relevant portions of the standard, but haven't
been able to convince myself of the correct interpretation of the
following code.  It seems it's not just me - as I'll show below, two
different compilers, both claiming conformance, also disagree.

Here's the code.
-----------------------------
#include <iostream.h>

void u(const int&)
{ cout << "u(const int&)" << endl;
}

void u(int&)
{ cout << "u(int&)" << endl;
}

void v(int)
{ cout << "v(int)" << endl;
}

void v(const int&)
{ cout << "v(const int&)" << endl;
}

#define T(x) cout << __LINE__ << ": " #x "-> "; x

int
main(int,char**)
{ int i = 1;
 const int ci = 2;

 T(u(i));
 T(u(ci));
 T(u(1));

 cout << endl;

 T(v(i));
 T(v(ci));
 T(v(1));

 return(0);
}
------------------------

HP's aCC (missing the absolute latest set of patches, but I don't recall
seeing any indication of a patch in this area) compiles the whole thing
with no complaints.  The result produces the following output:

26: u(i)-> u(int&)
27: u(ci)-> u(const int&)
28: u(1)-> u(const int&)

32: v(i)-> v(const int&)
33: v(ci)-> v(const int&)
34: v(1)-> v(int)

The first three lines make sense to me:  We are given a choice between
references and const references, and we choose the reference when we
have a non-const lvalue, the const reference otherwise.  (On line 28, is
a temporary copy made?)

Lines 32 and 33 make sense if you assume a preference, in overloading,
for a const ref T over a T.  This is a reasonable thing to do -
certainly for class types - but I can't seem to find language to justify
it.  Line 34, on the other hand, is a puzzle:  How does it differ from
line 33?  The only thing I can think of is that 34 requires creation of
a temporary while 33 doesn't - but again I don't see where that fits
into overload resolution.

Sun's CC V5.0, invoked with -compat=5, gives different results.  First,
it won't even compile the code as written:

"w.c", line 33: Error: Overloading ambiguity between "v(int)" and
"v(const int&)".

Replacing that line with one that prints an appropriate message, we get
code that compiles and runs, to produce the following output:

26: u(i)-> u(int&)
27: u(ci)-> u(const int&)
28: u(1)-> u(const int&)

32: v(i)-> v(int)
33: overload ambiguity
34: v(1)-> v(int)

Lines 26-28 are the same as for aCC, but line 32 differs - aCC chose the
int& version.

Can anyone explicate?
       -- Jerry
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]