Re: overload resolution and conversion ops
On 17 mai, 00:13, "Alf P. Steinbach" <al...@start.no> wrote:
* James Kanze:
On 16 mai, 14:24, xtrigger...@gmail.com wrote:
I was reading Mr. Alexandrescu's mojo article and I've a hard
time understanding the following.
Let's suppose I have:
//code
struct A {};
struct B : A {};
struct C
{
operator A() const { return A(); }
operator B() { return B(); }
};
void F( A const & ) {}
void F( B const & ) {}
C const H() { return C(); }
int main()
{
F( C() ); // 1. called with a non-const rvalue
F( H() ); // 2. called with a const rvalue}
}
//end code
I understand that if I have a const "C" (rvalue or lvalue,
here it does not matter) the only option when calling "F"
would be to use
C::operator A() const -> F( A const & )
Correct. The C::operator B() conversion operator cannot be
called (is not a viable function, in the words of the
standard).
Agreed.
In the case I have a non-const "C" it seems that the
compiler chooses
C::operator B() -> F( B const & )
my understanding of the article is that this is because
since B is derived from A, it's a better match than the
base class.
I do not understand then why the constness of operator A()
makes the difference.
It's rather the non-const-ness of operator B() that makes
the difference. Because the operator is not const, it
cannot be called on a const object.
But here you have overlooked the call 'F( C() )'.
Not entirely, but I was mainly concerned with the call
generating the error.
Remove the call 'F(H())' and the const on op B still makes a
difference... :-)
Well, it will certainly make a difference in some cases. The
const-ness is part of the type, and will always play some role
in overload resolution. As you say, I was mainly concerned with
the F(H()).
OK, I don't understand this, even after scrutinizing the
standard, but I recognize that your explanation isn't it, that
it ignores the really relevant aspects.
I know that as well. Overload resolution is one of the most
complicated subjects in the standard, taking a full 15 pages of
text, all of it relevant.
I should understand it, after all it's basic!
Basically incomprehensible, you mean.
It's saving grace is that it ends up doing what you intuitively
would want, or generating an error (which can be eliminated by
an explicit cast), so you can write robust C++ without
understanding it.
, and I think I did understand it once, as one of the
volunteers helping Andrei with quality assurance on Mojo. But
darned if I now can get my head around this (same predicament
as the OP)!
If I remove it and make it just
C::operator A()
my guess would be that that when calling "F" I would always
get a call to F( B const & ). But instead the thing does
not compile.
If the object is const, only const functions can be called
on it. If you remove const everywhere, then no functions
can be called on the object. Whence your error.
Again, here you have overlooked the call 'F( C() )'.
Obviously, I was talking about the case of a const C. But
you're right, I should have made that clearer.
Here's a FLAWED analysis, with some facts. Would appreciate
it if you could return my help in pointing out flaw in your
above explanation, by pointing out flaw(s) in this... :-) :-)
Well, I can try, a little, but quite frankly, overload
resolution is too complicated for me. I just keep it simple,
and trust the compiler.
In well designed code, it shouldn't matter which function is
called. If it matters, they shouldn't be overloaded. But you
can't always avoid the problem with constructors (since you
can't give them different names), and the problem can definitly
occur when software evolves, but must also retain some backwards
compatibility. And of course, there is still the problem of a
call being ambiguous.
The facts seem to stand.
The call
F( C() )
can be resolved as
F( C().operator A() ) // calls F( A const& )
or
F( C().operator B() ) // calls F( B const& )
Data point matrix (apparently these are facts):
case const on op A const on op B result
0 no no Ambigious, F(A) or F(B)
1 no YES Ambigious, F(A) or F(B)
2 YES no F(B)
3 YES YES Ambigious, F(A) or F(B)
That's what g++ (the only compiler I have available here)
says. The issues are complicated enough that I wouldn't
count on it being right. (Comeau, or another compiler using
the EDG front-end, has the best chance of being right, since
one of the authors of the EDG front-end is also the author
of section 13 in the standard. But even then, the issues
are complicated enough that a small slip up cannot be
excluded.)
The most interesting case seems to be case 1. Here, from na=EFve point
of view, the class derivation relationship wants F(B), most specific,
but the extra const "conversion" wants F(A), fewest "conversions".
However, let's first consider cases 0 and 3, where op A() and op B()
compete directly, on equal footing, so to speak.
Hm, standard, what do you say?
OK, =A713.3.3.2/2 is the top-level of how to rank implicit conversion
sequences, paraphrased:
Best: Standard conversion sequence
So-so: User defined conversion sequence
Worst: Ellipsis conversion sequence (a "..." formal argument)
What we have is two user defined conversion sequences to be
compared (from C to A or B result), so that top level ranking
doesn't come into play directly, but it can affect rankings
for sub-sequences. For a user-defined conversion sequence is
defined by =A713.3.3.1.2 to consist of a standard conversion
sequence followed by a (single) user defined conversion
followed by a standard conversion sequence. Sort of like
pre-conversion adjustment, real conversion, and post fixups.
Case 0
Seq Pre Real (user) Post Calls
s1 identity op A() A -> A const& F(A const&)
s2 identity op B() B -> A const& F(A const&)
s3 identity op B() B -> B const& F(B const&)
s2 is ranked lower than s3 because the post-conversion of s3
(recall, the post conversion is a standard conversion
sequence, not involving any calls) is more specific, at least
according to my reading of =A713.3.3.2/4. So that leaves s1 and
s3 to choose from.
-- 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, if not
that,
For once, something rather simple and intuitive: since s1 is
a proper subsequence of s2, s1 is better than s2. (Whatever
else this means, it means that s2 cannot be chosen.)
But s1 and s3 involve the same kinds of conversions.
We do not even need to know the exact rules. The
specificity of the result of s3 does not enter into the
ranking because that specificity is not of a standard
conversion sequence: specificity of class affects only
ranking of standard conversion (like, you have B, then a B
result, doing nothing, is better than direct "upcast" to
A, at least according to my reading of =A713.3.3.2/4). So
in this case s1 and s3, as I understand it, ends up with
same rank, and the call is ambigious.
Sounds right to me. You have a choice of calling F(A
const&) with an A, or F(B const&) with a B. Intuitively, if
that isn't ambiguous (supposing that there are no
differences in the way you obtain the A or the B), I don't
know what is.
*A key notion*: that "closeness" in inheritance only
affects ranking of standard conversions, not ranking of a
user-defined conversion.
Yes. A user defined conversion is a user defined
conversion, and there is no ranking between them, ever. All
user defined conversions are equal (with regards to the user
defined conversion---getting the reference to the object may
involve conversions.
Analysis for case 3 would be the same, so, case 1 then:
Case 1
Seq Pre Real (user) Post Calls
s1 identity op A() A -> A const& F(A const&)
s2 C -> C const op B() B -> A const& F(A const&)
s3 C -> C const op B() B -> B const& F(B const&)
Here again s2 is ranked lower than s3. But it would seem
that s1 should prevail, should be ranked higher than s3,
because of the const conversion in the pre-conversion.
However, =A713.3.3.2/3 tells us that
"User-defined conversion sequence U1 is a better conversion sequence
than another user-defined conversion sequence U2 if they contain the
same user-defined conversion function or constructor and if the
second standard conversion sequence [the "Post" above] of U1 is
better than the second standard conversion sequence of U2."
And it seems there is no other criterion for top-level
ranking of user defined conversion sequences.
That's the way I read it as well. I'll admit that it's NOT
what I would intuitively expect: I would expect that if
there were two conversion sequences involving user defined
conversions, the pre and the post would be considered. In
this case, that would mean prefering s1. But that doesn't
seem to be the case.
Hence, in order to for s1 to be better than s3 it would
have to involve the same conversion operator, and it would
have to be better in the post-conversion. The
pre-conversion is simply ignored, wrt. ranking. The
result is that s1 and s3 are ranked equally, ambigious.
Finally, analysis for case 2:
Case 2
Seq Pre Real (user) Post Calls
s1 C -> C const op A() A -> A const& F(A const&)
s2 identity op B() B -> A const& F(A const&)
s3 identity op B() B -> B const& F(B const&)
But this analysis fails, in the sense that it tells us
that since s1 and s3 involve different user defined
conversion functions, neither one is ranked better than
the other. So according to this analysis they "should" be
equally ranked, ambigious. But they're not.
At least with the compiler(s) we're using. Your reasoning
seems to hold. (But there *are* 15 pages to be considered,
so the possibility that we've overlooked something can't be
excluded.) I'm having a hard time understanding why this is
different from:
struct C
{
operator std::string const() { return "const" ; }
operator std::string() { return "non-const" ; } ;
} ;
int
main()
{
std::string s1( (C()) ) ;
std::cout << s1 << std::endl ;
return 0 ;
}
In this case, g++ 4.2.1 says ambiguous as well. So maybe
you've just found a bug in g++ (or whatever compiler you're
using).
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34