On 10/14/07, Chad Walters <chad@powerset.com> wrote:
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<fixed_point> would give false. He can not modify the library. He has hack the problem by specializing boost::is_arithmetic for the fixed_point class. Of cause, it is the fault of the library. But I think for the user that is the best way to make the library work in this case, isn't it?