On December 14, 2015 11:39:50 AM EST, Robert Ramey
On 12/14/15 5:15 AM, Andrzej Krzemienski wrote:
Most of what you quoted/replied to was from me, not Andrzej.
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
I'm confused. If that's the behavior of safe, why do you need safe_..._range?
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.
Why not?
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.
Why doesn't that suffice for all use cases? ___ Rob (Sent from my portable computation engine)