|
Boost Users : |
From: Peng Yu (pengyu.ut_at_[hidden])
Date: 2007-10-16 12:20:04
On 10/14/07, Chad Walters <chad_at_[hidden]> 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?
Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net