From: "Tobias Schwinger" <tschwinger@neoscientists.org>
Terje Slettebø wrote:
From: "Tobias Schwinger" <tschwinger@neoscientists.org> Further I doubt there is a chance of weakening the "no-match-overload" in any other way to match worse than a function with one user defined conversion per argument.
Actually, there is...: [...]
First of all thanks for taking the time to write such an encouraging reply to my capitulation ;+).
It seems to me that we are referring to different parts of this discussion:
Ah, yes, sorry about that.
Daniel Wallin writes:
check_add<float, int*>
Would trigger a compilation error otherwise.
'has_plus_op<float,int*>' fails for the same reason (the expression inside the function call becomes invalid).
I tried putting the arguments inside the expression into classes with an implicit conversion operator - but failed coming up with a "no match overload" weak enough. According to 13.1-3 I don't think there is.
Right, especially 13.3.1.2: "If no operand of an operator in an expression has a type that is a class or an enumeration, the operator is assumed to be a built-in operator and interpreted according to clause 5." This means that if you do float + int *, it won't even consider an overloaded operator+, and you get an error.
'enable_if' could probably do the trick - using a modern compiler supporting it, that is.
Yes. As mentioned in another posting, approach taken in the library I uploaded is to first check the cases with built-in types, and then - if it passes that check - do a check using an overloaded operator+, taking a type that is convertible from anything (...). Regards, Terje