Re: [boost] [safe_numerics] One more review

Subject: Re: [boost] [safe_numerics] One more review
From: Robert Ramey (ramey_at_[hidden])
Date: 2017-03-11 18:17:23

On 3/11/17 9:51 AM, Oswin Krause via Boost wrote:
> On 2017-03-11 10:00, Antony Polukhin via Boost wrote:
>> - What is your evaluation of the design?
>>
>> Looks good, simple to use.
>>
>> I'd like to see an additional statefull ExceptionPolicy that remembers
>> that an UB was triggered, but does not throw at all. Here's how it
>> could be used:
>
> I would also vote for a class similar like that. However, i would move
> the whole interface closer to expected in that case. e.g. I might want
> to know what happened. Lets call this class checked<int>.
>
> The behaviour should be like this: all operations between a checked<int>
> and other integers should work independent of the state of the
> checked<int> object. However the value of a checked<int> can only be
> obtained using:
>
>
> checked<int> myInt= ...
> if(myInt){
>     int val = myInt.value();
> }else if(myInt.error() == overflow){
>     //some error handling here
> }else{
>     //some terminal error handling here
> }

cases like this I think would be better handled by using the Checked 
Integer module of the library directly.

int myInt;

checked_result<int> val = checked::add(myInt, 42);
if(val.exception())
        // some eror handling
else
        // ?

myInt = val; // convert modadic val back to simple integer.

The nature of the a boost library doesn't really promote this but it 
often happens there there is a sub component of a library which is 
useful in it's own right.  But being a sublibrary - not reviewed 
independently, makes it sort of invisible to all but the most ardent 
boost spelunkers.  It's a weakness in our system.  I don't see a way to 
address it without make the whole process even more complex.

Robert Ramey