Re: [Boost-users] [numeric conversation] behavior on std::numeric_limits<double>::max() + eps with numeric_cast

Subject: Re: [Boost-users] [numeric conversation] behavior on std::numeric_limits<double>::max() + eps with numeric_cast
From: Olaf Peter (ope-devel_at_[hidden])
Date: 2014-06-09 14:13:41

Am 09.06.2014 14:06, schrieb Brandon Kohn:
>
> On 6/9/2014 02:53 AM, Olaf Peter wrote:
>>              std::cout << boost::numeric_cast<double>(z) << '\n';
>>
>> I would expect that an exception is thrown which isn't, the output is
>> 1.79769e+308
>> 1.79769e+308
> In the case of conversion to the same type I believe a trivial fall
> through is done which just returns the value, so this is the expected
> behavior.
OK.
>
>> and as second: If I write my onw UDT as shown in the tutorial like:
>>
>> it doesn't change the result - is this the right way?
>>
> It's hard for me to tell just from the code snippets you've provided.
> Could you send me a small test which shows the problem you're having?
>
attached my 'playground', it's basically the UDT example simplified 
extended with math_round capabilities. The range_checker also checks on 
finite values, but I'm not sure if this is really required (I would say 
yes, since operator[<,>} wouldn't work on NaN or Inf). Line 486 doesn't 
compile - vice versa doesn't work for some reasons.

The goal is to check the rounding near the type specific min/max 
boundaries due to math_round using value +/- 0.5 and floor/ceil. Maybe I 
should use float and long long int?

Is there a way to get a stack trace using boost to find the code part 
which triggers the exception in the source? I mean here it would be e.g. 
line 478 if x would be greater MAX_INT.

Is it usefull to add boost exception infos about the calling args in 
overflow_handler? Is there a clever way since the overflow_handler isn't 
templated so I have no info about the type and value to be converted.

Where is the error for the vise versa cast at line 486?

Thanks,
Olaf