Re: [boost] [review][constrained_value] Review of Constrained ValueLibrary begins today

Subject: Re: [boost] [review][constrained_value] Review of Constrained ValueLibrary begins today
From: Robert Kawulak (robert.kawulak_at_[hidden])
Date: 2008-12-06 08:30:50

> From: Gordon Woodhull

> My view is that you just can't actually use any of 
> the built- 
> in operators, but the same operations exist if you figure in 
> a little  
> epsilon.  Note that although a very small number like 1e-10 
> works most  
> of the time, epsilon should really be proportional to the 
> size of the  
> arguments.

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).

> The final version should  
> have sizeof tests, which should pass on the major compilers.

Sounds like a good idea.

> I would like to see the space costs spelled out in each section.  I  
> didn't have any trouble understanding that anything you specify as a  
> template parameter is free, anything that is changeable at 
> runtime is  
> going to cost exactly what you'd expect, but sometimes it is nice to  
> be reassured.

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.

The docs already say:

"The implementation takes advantage of potential capability of the compiler to
perform EBO (the Empty Base-class Optimization), so for example the following
expression should be true: sizeof( bounded_int<int, 0, 100>::type ) == sizeof(
int )
However, lack of EBO capability may cause constrained objects to have
significantly larger size than the corresponding underlying value types."

Thanks for your time and best regards,
Robert