Subject: Re: [boost] review request: addition to type_traits library ofis_less_comparable<T, U> and others
From: Christian Schladetsch (christian.schladetsch_at_[hidden])
Date: 2009-12-07 06:36:39
On Mon, Dec 7, 2009 at 9:12 PM, John Maddock <john_at_[hidden]> wrote:
> operator name in <functional> proposed name (existence)
>> proposed name (existence and non void return type convertible to
>> < less has_operator_less
> 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>
> 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?).
Is "less ugly" than
But is it 'better'?
Using boost::operators::[name] has enough potential benefits that I don't
see why it should be rejected so casually:
* boost::operators::[tab]::[tab] works better with Intellisense
* it is factored over the operators, which provides a common structure for
all operators in a tree
* it provides a single type that designates each operation uniquely. that
is, operators can become first-class objects.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk