From: "michael toksvig" <michaeltoksvig@yahoo.com>
"Rob Stewart" <stewart@sig.com> wrote in message news:200509161700.j8GH0nHo017101@shannonhoon.balstatdev.susq.com... It's surprising for the result type to have a less restrictive range than the inputs.
add two numbers in the 1-10 range, and you invariably end up with a number in the 2-20 range
Yep. However, when considering constrained ranges, I find it surprising that the result would be *permitted* to exceed the constraints of the inputs. IOW, I'd have expect the result to be constrained to be 2-10. Yes, that means that combinations exist that violate that constraint, but at least it wouldn't surprise me.
that is both more (in the low end) and less (in the high end) restrictive than the inputs
Yes, but I find that surprising.
i don't find that surprising at all; indeed, i wouldn't consider using a checked integral class that did not reflect that
Consider that the class is used to model, say, permitted voltages in an electonic circuit. Say that an input on the circuit is constrained by only being able to support voltages of 2-5V. (If you connect two batteries in series, the voltages add.) If each battery's voltage is expressed with a checked integer of the 2-5V range, and their voltages are summed, your result would be a checked integer with a 4-10V range. That exceeds the permitted input voltage range and two batteries of 4V each would blow the input. How would you handle that in your model? In my approach, the result would be a value with a 4-5V range. That fits within the 2-5V range and so a successful sum of battery voltages doesn't exceed the range of the input. Unless I've missed something, your approach requires a runtime check to see whether the actual result of the addition exceeds the input voltage range during some later computation or comparison. My approach catches the range error during the addition. -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;