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

Subject: Re: [boost] safe integer library -- the scope
From: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2015-12-14 03:43:25

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

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()]

Regards,
&rzej