Re: [boost] [constrained_value] Constrained Value review results

Subject: Re: [boost] [constrained_value] Constrained Value review results
From: Gordon Woodhull (gordon_at_[hidden])
Date: 2010-09-14 03:41:43

Hi Thorsten,
 
> 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,
Gordon