
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