Re: [boost] [safe_numerics] review

Subject: Re: [boost] [safe_numerics] review
From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2017-03-11 15:42:10

AMDG

On 03/10/2017 09:29 PM, John McFarlane via Boost wrote:
> On Fri, Mar 10, 2017 at 11:59 AM Robert Ramey via Boost <
> boost_at_[hidden]> wrote:
> 
>> 
>> I'm all ears.  One thing I do NOT see is saturate.  I've seen it
>> mentioned in several places - but I'm not convinced.
>>
> 
> You mean you don't see the need for it? It comes up quite often as a
> strategy for dealing with overflow and a safe integer type seems like a
> good place to house it. Even it it isn't implemented now, a policy
> interface which allows users to implement it is going to give the library
> more users who use it to make their integers safe - surely the point of the
> exercise here.
> 

It should be possible to handle saturation
with the following extension:
- If the ExceptionPolicy returns non-void,
  then the value it returns will be converted
  to the result type (the safe type, that is,
  not the stored type).

This requires two additional pieces to work:
- The ExceptionPolicy needs to distinguish
  between positive and negative overflow.
- There need to be special values that can
  convert to the min and max values of safe_base.

// Hypothetical saturate ExceptionPolicy:

template<class T>
struct min_value_t {
  constexpr T operator()() const
  { return std::numeric_limits<T>::min(); }
};

template<class T>
struct max_value_t {
  constexpr T operator()() const
  { return std::numeric_limits<T>::max(); }
};

template<template<class> class F>
struct special_value_t {
  template<class T,
    class = typename enable_if_c<is_safe<T>::value, void>::type>
  constexpr operator T() const { return F<T>()(); }
};

constexpr const special_value_t<min_value_t> min_value;
constexpr const special_value_t<max_value_t> max_value;

struct saturate {
  static auto overflow_error(const char *) { return max_value; }
  // ...
};

> 
>> Note that I'm not a saint. I DO permit n to be uninitialized.  I did
>> this because it's so common and I want the library to be useful on
>> legacy and embedded code.  I've got a lot of reservations about this and
>> could change my mind.
>>
> 
> <snip>. And of the list of things that makes fundamental
> scalar types unsafe, indeterminate value of default-initialized instances
> ranks higher than either overflow or divide-by-zero in my experience.
> 

  Why not let the ExceptionPolicy decide?
Just add an uninitialized_error(const char*)
to ExceptionPolicy.  Combined with my hypothetical
extension above, this would also allow automatic
zero-initialization.

  Incidentally, I'm not personally very concerned
about indeterminate values, as valgrind works quite
nicely for flushing out such problems and they're
usually easy to fix.

In Christ,
Steven Watanabe