Subject: Re: [boost] [type_traits] adding is_less_comparable<T>, etc.
From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2009-09-04 12:06:22
FrÃ©dÃ©ric Bron wrote:
> Please find at https://svn.boost.org/trac/boost/browser/sandbox/type_traits
> and at http://dl.free.fr/tK0BwIzYy my new proposal according to review
> * now using 2 template parameters so that it is possible to check if 2
> different types are comparable
> * now using factory functions instead of static references
> * now using type_traits yes_type and no_type
> * the doc. is alphabetically sorted
> * the doc. has been updated for clarity
> * the tests have been modified to include new possibilities
> The code has the following properties:
> * returns true if t<u is meaningful and returns a value convertible to bool
> * returns false if t<u is meaningless.
> * fails with compile time error if t<u is meaningful and returns void;
> on this point, please have a look at the comment below.
There are some tricks involving overloading the comma operator
(The built-in comma operator can take a void argument.)
Unfortunately, I've never been able to come up with a completely
bulletproof method that can handle types which themselves overload
the comma operator.
>> I'd like to see something done to detect the void return, with a meaningful error message though.
>> It is possible to extract the return type from a function pointer and check for that being the same
>> as void, so it might be possible to form a pointer to the operator. You'd have to know whether the
>> argument types are built-in types, in which case you can short-circuit the answer. If not, you'd have
>> to determine whether the operator is a free function or a member in order to create the proper
>> pointer type. Once you have that, you can extract the return type and compare it. Finally, you can
>> use BOOST_STATIC_ASSERT to complain if the return type is void.
> This looks too difficult for me! Can we keep it for a future update,
> unless you can show me how to do it?
There is no way to get a pointer to the correct operator<.
operator< may be overloaded, in which case you need to
know the signature (at least approximately) to get a pointer.
Even worse, since ADL doesn't apply when taking the
address of a function, there is no way to guarantee that
the correct function is in the overload set at all.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk