Re: [boost] [review][constrained_value] Review ofConstrained ValueLibrary begins today

Subject: Re: [boost] [review][constrained_value] Review ofConstrained ValueLibrary begins today
From: Gordon Woodhull (gordon_at_[hidden])
Date: 2008-12-10 15:39:36

On Dec 9, 2008, at 7:28 PM, Robert Kawulak wrote:
> From: Gordon Woodhull
>> My yes vote is still conditional on your cooperation with us on
>> letting floating points work, because the library would not
>> be useful  to me otherwise.
>
> Technically, there's nothing in the code that would disallow the use  
> of floats,
> only that there is the warning in the docs. I have already stated  
> (though maybe
> not clearly enough, so I will try again now ;-), that I will explain  
> possible
> issues with floats and make the warning sound less categorical. Is  
> this what you
> expect?

Yes, that is exactly what I'm looking for.  As many have pointed out,  
maybe the Fear Uncertainty and Doubt are for good reasons, but this  
could be worded more gently so that beginning users don't get the  
impression that they shouldn't be using floats at all.

However, there might be one problem with the code:

> The assertions test the invariant exactly the same way, they use the  
> predicate.
>
>> Is this only in the bounded part of the library?
>
> No, the constrained class contains those assertions.

I've looked at the code now (it's very clear!), and I understand what  
the assertions do: they double-check that the error handler is  
fulfilling the contract of not returning if the constraint fails.

I think this is a valuable feature in debug mode but would not be wanted
1) in performance critical apps (the extra test matters)
2) if we've established that there's no way a floating point predicate  
is always going to provide consistent results.  (I know you're laying  
your hopes on consistent truncation.)

Of course, if you allow the asserts to be disabled by macro or policy,  
then you're also allowing the monitored values use case.  I understand  
that you don't want to support this (certainly the nomenclature is  
wrong), but it would be nice if you would allow people to experiment.

The error policy could somehow declare that it doesn't want to be  
double-checked, e.g. by deriving from please_dont_double_check_me;  
there doesn't need to be a separate parameter to constrained_value.

BTW, I find the ignore example confusing because it's checking whether  
the old value still satisfies the constraint.  (Doesn't it know this  
by now?)  To be honest, I had to compile it and say "huh?" to figure  
this out.  This results in three invocations of the predicate on a  
successful assign.

> Value should be changed _after_ calling the predicate to ensure  
> strong excepiton
> guarantee.

Duh, right.  Fast fingers.

>> I figured this was
>> the point
>> of having an error policy - everyone has their own idea how
>> they want
>> to handle errors.
>
> Error policy and the assert are two different things. Error policy  
> guarantees
> the invariant, the assertion verifies it (and thus verifies the  
> contract).
> Assigning an invalid value is a different kind of error than  
> breaking the
> contract.

I hope that you will consider loosening the contract in a later  
version to allow more use cases.

Gordon