Re: [boost] safe integer library -- the scope

Subject: Re: [boost] safe integer library -- the scope
From: Rob Stewart (rob.stewart_at_[hidden])
Date: 2015-12-14 08:01:24

On December 14, 2015 3:43:25 AM EST, Andrzej Krzemienski <akrzemi1_at_[hidden]> wrote:
> 2015-12-12 1:18 GMT+01:00 Robert Ramey <ramey_at_[hidden]>:
> 
> > In the context of this library the safe_range ... are important for
> a very
> > special reason.  The bounds are carried around with type of
> expression
> > results.  So if I write
> >
> > save<int> a, x, b, y;
> > y = a * x + b;
> >
> > runtime checking will generally have to be performed.  But if I
> happen to
> > know that my variables are limited to certain range.
> >
> > safe_integer_range<-100, 100> a, x, b, y;
> > y = a * x + b;
> >
> > Then it can be known at compile time that y can never overflow so no
> > runtime checking is required.  Here we've achieved the holy grail:
> >
> > a) guaranteed correct arithmetic result
> > b) no runtime overhead.
> > c) no exception code emitted.
> > d) no special code - we just write algebraic expressions
> >
> > This is the true motivation for safe_..._range

Why isn't that the behavior of your safe type in the first place? That is, what benefit does your safe type offer that it shouldn't just be supplanted by the range type?

> Ok, now I think I understand the scope of the library. You give me the
> tool
> for representing a mathematical notion of an integral number within
> *some* limited range. The contract is:
> 
> You guarantee:
> 1. Either correct result or a compile time error or a run-time
> exception.
> 2. No memory management: you will only take the space of one scalar
> type.
> 
> I specify the range of the representable values. I can say:
> 1. "From -100 to +100", or
> 2. "Whatever range 'int' as on my machine".
> 
> But if I got it right, I would say that the choice of the name, and
> the
> interface do not indicate the intent as clear as they could. Imagine
> the following alternative interface:
> 
> small_int<p_range<-100, 100>>; // range-based policy
> small_int<p_type<int>>; // underlying-type-based policy
> 
> In the first case, the user specifies the range, and the library can
> choose the best underlying type for the job.
> 
> In the second case, the user chooses the underlying type, and this
> implies the range [numeric_limits<T>::min(), numeric_limits<T>::max()]

That seems like a reasonable idea, but what about the latter is "small" and not "safe" that you think the name should be "small_int"?

Once you need two types to distinguish between a user-defined range, and a numeric_limits-defined range, why not just use two template names, like safe_range and safe_int? That would eliminate your p_range and p_type policies.

However, since min() and max() are now constexpr, that all can be collapsed into a single template with three parameterizing types: the underlying type, the minimum, and the maximum:

template
<
   class T
 , T Min = std::numeric_limits<T>::min()
 , T Max = std::numeric_limits<T>::max()
>
class safe;

___
Rob

(Sent from my portable computation engine)