On 10/14/07, Chad Walters
It's not entirely clear from your description if you really need to have is_arithmetic be true for your fixed_point class or if you just want to have some predicate that is true for both the built-in arithmetic types and your fixed_point class.
If the former, then you will likely run afoul of problems, for the reasons previously pointed out.
Hopefully it is the latter — in which case you should just define your own predicate with the appropriate logic (true for fixed_point or is_arithmetic types).
Chad
The problem is raised in the following situation.
Suppose semantically it makes sense a class, rectangle, accept any
arithmetic type T (in a broader sense, including the fixed_point class
mentioned in the original post). However, the library builder did not
expect that the users would someday provide a type such as
fixed_point.. Therefore, it was perfectly fine that the library
builder use boost::is_arithmetic to test whether the type is an
arithmetic (broader sense) type, in the implementation of the class.
template <typename T>
class rectangle;
But later on, some use what to extend the rectangle of even finer
resolution. Therefore, he supplies the fixed_point class. But found
that the library simply does not accept the code, because
boost::is_arithmetic