Topic: overloading: reference vs. lvalue-transformation
Author: nospam@nospam.ucar.edu ("Thomas Mang")
Date: Sun, 23 Jan 2005 01:16:04 GMT Raw View
Greetings,
I start this thread after a discussion in comp.lang.c++.moderated.
Given this program:
void foo(int);
void foo(int const &);
int main()
{
int i(0);
foo (i);
}
Comeau and GCC 3.3.1 complain ambiguity (BCC 5.5.1 picks the first, but that
must be wrong).
Calling the first is lvalue transformation with rank of exact match, calling
the second is identity conversion with rank of exact match.
13.3.3.2/3 says:
Standard conversion sequence S1 is a better conversion sequence than
standard conversion sequence S2 if
- S1 is a proper subsequence of S2 (comparing the conversion sequences in
the canonical form defined by 13.3.3.1.1, excluding any Lvalue
Transformation; the identity conversion sequence is considered to be a
subsequence of any non-identity conversion sequence) or.....
My reading of this bullet is that it pretty much clearly says the second foo
should be called - because of the part "the identity conversion sequence is
considered to be a subsequence of any non-identity conversion sequence" -
independet of the fact that the non-identiy conversion sequence consists of
only an Lvalue-Transformation, since there is no word such a sequence will
become "graded up" to identity conversion; it still remains officially
non-identity conversion.
My questions:
1) is my reading wrong and the 2 compilers are correct?
If yes, what part did I read wrong?
2) If my reading is correct, was this intended behavior and the compilers
are broken, or is it a defect?
Thomas
---
[ 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://www.jamesd.demon.co.uk/csc/faq.html ]
Author: belz@kolumbus.fi (Mikael =?ISO-8859-1?Q?Kilpel=E4inen?=)
Date: Sat, 5 Feb 2005 03:56:28 GMT Raw View
Thomas Mang wrote:
> My questions:
>
> 1) is my reading wrong and the 2 compilers are correct?
The compilers are right, in the same page (std), in the reference binding
item, there is the exactly same example and std explicitly states it is
ambiguous.
> If yes, what part did I read wrong?
Maybe it is a bit confusing but you compare the sequences
without the lvalue transformations.
Mikael
---
[ 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://www.jamesd.demon.co.uk/csc/faq.html ]
Author: nospam@pop.ucsd.edu ("Thomas Mang")
Date: Sat, 5 Feb 2005 18:03:30 GMT Raw View
"Mikael Kilpel inen" <belz@kolumbus.fi> schrieb im Newsbeitrag
news:ctnl52$e1i$1@phys-news1.kolumbus.fi...
> Thomas Mang wrote:
>
> > My questions:
> >
> > 1) is my reading wrong and the 2 compilers are correct?
> The compilers are right, in the same page (std), in the reference binding
> item, there is the exactly same example and std explicitly states it is
> ambiguous.
Oh yes, just some subbullets later....
[Still my opinion is the normative text contradicts the example.]
>
> > If yes, what part did I read wrong?
> Maybe it is a bit confusing but you compare the sequences
> without the lvalue transformations.
I know that.
But the implication is the original non-identity conversion sequence will
become now an identity conversion sequence because of omitting lvalue
transformation, in order to resolve the last sentence of this subbullet to
reflect the intended behavior.
However, at the time 13.3.3.2 is entered, the formal conversion sequences
are already determined. Unless the Standard says otherwise (it doesn't in
the normative text, at least I couldn't find it) you have still
identity-conversion vs. non-identity conversion.
As Mike Miller has pointed out in private correspondance (I have contacted
EDG for clarification, since I got no response in this group), it could have
said "empty conversion sequence is subsequence of any non-empty conversion
sequence", which makes the issue different. But no, it says otherwise.
Maybe a defect, maybe not, possibly just confusing. However, using some
better words couldn't hurt at all IMHO.
Thomas
---
[ 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://www.jamesd.demon.co.uk/csc/faq.html ]