Subject: Re: [boost] review request: addition to type_traits library ofis_less_comparable<T, U> and others
From: FrÃ©dÃ©ric Bron (frederic.bron_at_[hidden])
Date: 2009-12-07 05:23:15
> I don't like operator_less_has_standard_behaviour at all. Â In fact is there
> really any point to it?
> Why not simply:
> has_operator_less<T, R = bool>
It would be:
has_operator_less<T, U, R=bool>
as we said in previous discussion we want to address the case where we
compare T with U!=T.
> Where R is the expected return type. Â In all but a vanishingly small number
> of cases R will be bool. Â If you really want to support the "don't care"
> case for a return type, use has_operator_less<T, dont_care> where
> "dont_care" is a special placeholder type that you define (could use a
> better name though?).
the "don't care" case was a strong requirement from previous discussion.
I like your proposed solution has_operator_less<T, U, dont_care>
dont_care would have to be an empty class maybe boost::type_traits::dont_care?
>> + Â Â Â Â Â plus Â Â Â Â Â Â Â Â Â Â has_operator_plus
> These are more complex because we often have mixed mode arithmetic, what
> has_operator_plus<T, U> ?
right, that is what I meant
> So how about: has_operator_plus<T, U = T, R = dont_care> ?
> Hard to decide what R should default to in this case, I'm tempted by the
> "permissive" case of dont_care because it will do the right thing in more
> mixed arithmetic cases, but the alternative would be to default R to T I
I am in favor of dont_care
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk