Subject: Re: [boost] [constrained_value] Constrained Value review results
From: Gordon Woodhull (gordon_at_[hidden])
Date: 2010-09-14 03:41:43
> As for the member vs. non-members, then I have no strong preference, but remain convinced that changing state of objects with a non-trivial invariant is best done by a member function.
I happen to agree with you here, but this seemed to be a debate which was going nowhere, and eventually these design decisions are up to the discretion of the author. There wasn't a huge efficiency gain to making change_constraint a method, because it would still have to construct-and-swap as long as the constraint could be changed. Perhaps with a finer-grained abstraction - but I'm digressing.
> As for the floating point problems, then I have not read any subsequent threads on this. My recollection was that we did solve the problem during the discussion (was it using <= and >= exclusively and always truncating the bound to 64 bits?).
There's an interesting thread on floating point FUD which I linked to.
Yes, I think that was the agreed solution. Efficiency be damned for an obsolescent architecture. It is interesting to see that numeric::interval came to the same conclusion about round-tripping the bounds to memory. Their bounds are also closed, included. Those guys could have set us straight a lot quicker, but it's nice to see convergent evolution.
Cheers, and thanks,
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk