Re: [boost] Checked Integral Class

From: Rob Stewart (stewart_at_[hidden])
Date: 2005-09-16 17:54:17

From: "michael toksvig" <michaeltoksvig_at_[hidden]>
> > "Rob Stewart" <stewart_at_[hidden]> wrote in message 
> > news:200509162032.j8GKWh51025673_at_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_at_[hidden]
Software Engineer                     http://www.sig.com
Susquehanna International Group, LLP  using std::disclaimer;