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