Boost logo

Boost :

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

"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, gregod at, cpdaniel at, john at