Robert wrote:
The epsilon solution has already been proposed, but as I understand this (correct me if I'm wrong) it wouldn't work either:
From: Zach Laine
Yet another use case would be "close enough is good enough". If the bounds are within a user-defined epsilon of either boundary.
If I understand correctly, this does not solve the problem either. Let's assume you have two values: x and y, where x = y + eps (eps being the user-defined margin of error). One comparison of x and y would indicate their equality (the difference is not greater than eps), while another one might not if x got truncated in the meantime (and y didn't).
Thanks, I understand the problem now. I think we are all agreed that the library is orthogonal to any concerns about floating point and nothing needs to be changed in the code. IMO the warning should be toned down in the documentation. I wish the definition that Stjepan suggests were possible, but I don't see how a test can be designed that only only switches from unsatisfied to satisfied. Boost.Test has a good start on float predicates http://tinyurl.com/57u2sf - but no inequality and they require epsilon to be passed in or stored. I'll see if I can adapt them before Constrained Value is finalized... might be opening a can of worms, and any advice would be appreciated.
If I write everywhere that a feature implies no space cost, everyone will take this for granted and may be surprised when it turns out that on their compiler it is much worse than expected.
In that case, I would like it if the documentation said a feature "should not" take any extra space, linking to the explanation. In turn, the explanation can mention the sizeof test and link to the results so that people can find out quickly whether their platform will cooperate. I know it's a drag, but I think the features which do take extra space should mention that too. Also it might be worthwhile to point out that shared runtime mutable constraints with no overhead per constrained object are possible, using static members. (Or maybe that's too weird.) I might implement epsilon this way, as my impression is that numeric_limits<>::epsilon() is not useful for this purpose. Gordon