On 12/14/15 5:15 AM, Andrzej Krzemienski wrote:
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?
it is That is,
what benefit does your safe type offer that it shouldn't just be supplanted by the range type?
safe<T> can be used as a drop in replacement for T . safe...range cannot.
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;
That's exactly what safe<T> is.
Current implementation has more of these policies (e.g., for how you want to report overflow).
Is there a question in there somewhere?