Thorsten Ottosen wrote:
6. My main use case would be to use constrained floating point values, but the docs state:
"Why C++'s floating point types shouldn't be used with bounded objects? [...] there exist a number of myths of what IEEE-compliance really entails from the point of view of program semantics. We shall discuss the following myths, among others: [...] "If x < 1 tests true at one point, then x < 1 stays true later if I never modify x."
I don't fully understand this...AFAIK, this is not allowed for an IEEE complient implementation. How could we ever implement *anything* with respect to floats then?
With difficulty :-( Here's the thought experiment I came up with to verify that this is a real issue: * Imagine that the constraint is that the value is > 1, and that we're working with double's. * Imagine that the value being assigned is the result of some complex computation, and that the assignment function is inlined. * The compiler may now take the value being assigned as it exists in a register (from the computation), and perform a the check on that. * If the register containing the result is wider than a double (say Intels 80-bit long double), and the result is very slightly > 1, then the comparison will succeed. * The value is now stored in the object - and rounded down to double precision in the process. * The value may have been rounded down to exactly 1, and the constrait is now broken! Obviously if the constraint had been >= 1 then we'd be OK in this case (but then values very slightly < 1 may get rounded up, so we could eroniously reject a value). I think of any worse situations than these at present - which doesn't mean they don't exist - so whether or not you consider this an issue may depend on the use case. Presumably, a carefully written predicate that forces any rounding to occur prior to constraint checking would fix the issue, and I 100% agree that use with floating-point types is a very important use case. John.