Re: [boost] [review][constrained_value] Review of Constrained ValueLibrary begins today

Subject: Re: [boost] [review][constrained_value] Review of Constrained ValueLibrary begins today
From: Zach Laine (whatwasthataddress_at_[hidden])
Date: 2008-12-02 11:58:53

On Mon, Dec 1, 2008 at 5:30 PM, Robert Kawulak <robert.kawulak_at_[hidden]> wrote:
> // works with x as either bounded_int or int
> // without the need to call value()
> my_int y = std::max(static_cast<int>(x), 2);
>
> Yes, I know it's not perfect. I'd rather use unconstrained too. :P

Fair enough.

>> The note in the docs about the dangers inherent in using the library
>> with floating point types is well taken.  However, it would be nice if
>> you provided more support for such uses.  For instance, how about
>> providing a type that just checks for NaNs, or one that checks the
>> constraint every time you call .value(), so that eventually you'll
>> catch a range violation, even if it's masked by the underlying value
>> residing in a register for a while?
>
> There's already an assert every time a constrained object is modified -- is it
> something that you mean here?

Not quite.  As the quote in your Rationale section points out, the
same variable can have more than one value at different points in
time, without any mutating operations being performed on it, if it
moves out of a register into a memory location.  On x86, and probably
elsewhere, the registers have greater precision (80 bits for double)
than the memory locations (64 bits for double).

This means that testing against bounds at the point of modification is
not enough.  What might be enough, depending on the use case, would be
to test against bounds every time the underlying value is made
available to the outside world.  So that would mean placing a check in
value(), in operator double(), etc.

Yet another use case would be "close enough is good enough".  If the
bounds are within a user-defined epsilon of either boundary.

In any case, it sounds like this is not something that you're
interested in putting in to the library.

>> For instance, just glancing over the code, in
>> bounded.hpp, the implementations of within_bounds::is_below() and
>> within_bounds::is_above() appear to be wrong.  If
>> lower_bound_excluded() or upper_bound_excluded() is true in the
>> respective functions, shouldn't the result always be false?
>
> No, it shouldn't. Why do you think so?

Because I was reading too fast ;).  I misunderstood the
*_bound_excluded() functions to indicate whether a bound exists on
that side, not whether the bound itself is part of the interval.

Zach