Re: [boost] numeric_cast

Subject: Re: [boost] numeric_cast
From: Brandon Kohn (blkohn_at_[hidden])
Date: 2011-06-22 10:06:11

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