Boost logo

Boost :

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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk