From 1168629713153851098
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: f78e5,991a11e8ea03ee36,start
X-Google-Attributes: gidf78e5,public
From: Jerry Leichter <leichter@smarts.com>
Subject: Overload resolution and references
Date: 1999/03/24
Message-ID: <36F7E144.23FA@smarts.com>#1/1
X-Deja-AN: 458280041
Content-Transfer-Encoding: 7bit
Approved: Fergus Henderson <fjh@cs.mu.oz.au>
X-Original-Date: Tue, 23 Mar 1999 13:45:24 -0500
Content-Type: text/plain; charset=us-ascii
X-Complaints-To: news@news.unimelb.edu.au
X-Trace: izvestia.its.unimelb.edu.au 922256913 3150 128.250.29.17 (24 Mar 1999 06:28:33 GMT)
Organization: System Management ARTS
X-Auth: PGPMoose V1.1 PGP comp.std.c++ iQBFAgUANviF8uEDnX0m9pzZAQEm+gF+N3bMA1I79j2Knq3bHFr63cbznLBLjsCY 5z+eyC3V+sTHdWQ7SczDBeuluNTSBJpi =Dp04
Mime-Version: 1.0
NNTP-Posting-Date: 24 Mar 1999 06:28:33 GMT
Newsgroups: comp.std.c++

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              ]