Subject: Re: [boost] [type_traits] adding is_less_comparable<T>, etc.
From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2009-09-04 12:06:22
AMDG
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
> comments.
>
> * 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.
In Christ,
Steven Watanabe