On 6/22/2011 9:40 AM, Antony Polukhin wrote:
May be i am missing something, but I see no problem here. numeric_cast is designed to be as simple as possible. When the default polices are not what you need, you just define your own converter function via
template<typename Target, typename Source> inline Target my_numeric_cast ( Source arg ) { using namespace boost::numeric; typedef boost::numeric::converter<Target, Source, conversion_traits<Target, Source>, silent_overflow_handler> Converter ; return Converter::convert(arg); }
The problem with that solution is that it avoids an obvious problem when you have a lot of generative code using boost::numeric_cast. One would have to write a level of indirection to dispatch to either numeric_cast or my_numeric_cast depending on the conversion traits. If you have a lot of code with boost::numeric_cast that is quite a pain. Plus I think it is unnecessary.
or just directly call the required conversion function: converter<Target, Source, conversion_traits<Target, Source>, silent_overflow_handler>::convert(arg);
This really is no different than the solution my_numeric_cast above. The same problems apply.
So you do not need to create your own numeric_cast_traits. All you need to do, as a developer of a new numeric type, is just overload rounding functions for your type, add your type to std::numeric_limits.
I don't think this is good enough give the above stated issues.
Using your solution, we will break thecurrent behavior of numeric_cast function and the code that uses it. Library user won`t know, will the numeric_cast truncate or round via ceil, will it throw on overflows of silently ignore them. It will add more mess to the library, and less users will use it.
The defaults of numeric_cast_traits definition conform to the current behavior. It would only change if the users customize it. From that angle I think the greater flexibility comes with a bit more responsibility on the users side. Seems like a fair trade-off to me. Regards, Brandon