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
> issues with floats and make the warning sound less categorical. Is
> this what you
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
>> 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
> Value should be changed _after_ calling the predicate to ensure
> strong excepiton
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
> the invariant, the assertion verifies it (and thus verifies the
> Assigning an invalid value is a different kind of error than
> breaking the
I hope that you will consider loosening the contract in a later
version to allow more use cases.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk