Boost logo

Boost :

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
>> something)
>> < less has_operator_less
>> operator_less_has_standard_behaviour
>>
>
> 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?).

Perhaps

boost::has_operator_less<T,R=bool>

Is "less ugly" than

boost::operators::less::exists<T, R=bool>

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.

Christian


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk