Re: [boost] Re: Proposal for 'is_dereferenceable' and other templatemetafunctions

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
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