Re: [boost] numeric_cast

Subject: Re: [boost] numeric_cast
From: Fernando Cacciola (fernando.cacciola_at_[hidden])
Date: 2011-06-22 15:38:33

On 6/22/2011 2:15 PM, Vicente Botet wrote:
>
> Antony Polukhin wrote:
>>
>> 2011/6/22 Brandon Kohn<blkohn_at_[hidden]>:
>>> 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.
>>
>> Well, then here is some ideas.
>>
>> I am really afraid that some user will define such trait in header
>> file. Then all the code above the included header file will use the
>> old conversion trait, and below - the new trait. Include files became
>> dependent from their order. It is really error prone. User can forget
>> about the trait, change the inclusion order and get some really hard
>> detectable errors. So it would be more save not to modify the behavior
>> of boost::numeric_cast<N>(x) function, but rather create function with
>> some other name, for example boost::numeric_traited_cast<N>(x) and
>> create a separate namespace in boost::numeric for the traits.
>>
>>
>
> You are right that changing the implementation in this way can break some
> code in the future.
> Maybe we should be more conservative.
>
> The library has already a namespace boost::numeric so what about
> boost::numeric::convert_to/convert instead?
>
But this won't address the problem Brandon is trying to solve: namely, to allow 
numeric_cast<> --and no other function-- to really work with custom numeric 
types (which might have specific policy requirements).

I do understand Antony's concern, but I think is a bit of a red herring.
That is, I doubt it could really happen in practice, even though it technically 
could.

In any case, what is really important IMO is the keep the behaviour stable for 
the fundamental types. Thus a reasonable balance could be, IMO, that the 
additional traits is given already specialized for the fundamental types. This 
way, the extensibility is only really available for custom types.
Sort of the way numeric_limits<> works.

Best

-- 
Fernando Cacciola
SciSoft Consulting, Founder
http://www.scisoft-consulting.com