From: "michael toksvig" <michaeltoksvig@yahoo.com>
"Rob Stewart" <stewart@sig.com> wrote in message news:200509162032.j8GKWh51025673@shannonhoon.balstatdev.susq.com... 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?
given a constrained value type, CV<min, max, policy> and the following: CV<2, 5, some_policy> batteryA, batteryB;
you could decide either to do: CV<2, 5, compiletime_policy> input = batteryA+batteryB; // compiler will kindly alert you to the fact that there is a potential problem here
IOW, it won't compile, right? That still doesn't address what the return type of the addition expression is. I think you're saying that the return type would have the computed range and that the construction of input would fail because the computed and specified ranges differ.
or, if you are confident the potential problem doesn't occur: CV<2, 5, assert_policy> input = batteryA+batteryB; // at runtime, if something bad happens, it will assert
That means the result is validated when input is constructed, but still requires a template constructor which can accept a CV<X,Y,P> where X is not necessarily the same as the new object's minimum, Y is not necessarily the same as the new object's maximum, and P is not necessarily the same as the new object's checking policy. If the result of the addition is saved with the expanded range then the point at which you detect the overflow is removed from the point at which you caused it, which can be a problem. Since you've introduced the idea of compile_time_check and run_time_check (better names, I think), you leave it to the library user to decide which approach is most appropriate in the context. That's probably the only way to settle the issue. In my example, I'm thinking that the correct behavior is to disallow combining two 2-5V batteries if using the run_time_check policy because it is a design time problem I was trying to present. I can see, however, that such batteries don't necessarily have a full charge, so a specific combination of such batteries can actually work, so using run_time_check could be acceptable if you were modeling real circuits rather than designing them. [snip: Don't overquote, please] -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;