2015-12-12 1:18 GMT+01:00 Robert Ramey
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