Boost logo

Boost :

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


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

  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

Boost list run by bdawes at, gregod at, cpdaniel at, john at