On 03/07/2011 01:27 PM, Yufeng Zhang wrote:
On 03/03/2011 11:39 PM, Jason Merrill wrote:
I think rather that the problem is in build_conditional_expr; it
should have a template case that just determines the appropriate
type and then builds up a COND_EXPR with that type from the
unconverted operands, like we do for calls in finish_call_expr.
Thanks for the suggestion. I spent some more time looking into the
related code. If I understand it correctly, I think this is just what
build_x_conditional_expr in ./cp/typeck.c does:
Yes. The problem is that build_conditional_expr is actually trying to
do the conversions; it should just determine what the conversions would
be and then stop there. That's what we do with calls--we determine all
the desired conversions and pass them into build_over_call, which just
ignores them. Actually performing the conversions can wait until
instantiation tme.
Different from CALL_EXPR, the TREE_TYPE of a COND_EXPR is determined
by the TREE_TYPEs of its latter two operands. When the types of the
two operands are different, a conversion is attempted on each operand
type to match the type of the other operand; while for a CALL_EXPR,
its TREE_TYPE is independent from the TREE_TYPE(s) of its arg(s).
I don't think the difference is significant; a call to an overloaded
function also depends on the types of its arguments. We need to
determine the conversions from argument to parameter types in order to
select the right function, just as in a ?: expression we need to
determine the conversions from the 2nd and 3rd operands to a result type.
Jason
