From: Terje Slettebø (tslettebo_at_[hidden])
Date: 2004-09-18 06:36:41
>From: "Tobias Schwinger" <tschwinger_at_[hidden]>
> Terje Slettebø wrote:
> >>From: "Tobias Schwinger" <tschwinger_at_[hidden]>
> >>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
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 220.127.116.11:
"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 (...).
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk