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

Subject: Re: [boost] [review][constrained_value] Review of Constrained Value Library begins today
From: Gordon Woodhull (gordon_at_[hidden])
Date: 2008-12-06 03:12:37

Greetings,

Nice library.  I vote for inclusion with the proviso that Robert  
accept floating support provided by those of us that need it.

> - What is your evaluation of the design?

This is a very general design which I believe covers most use cases.

I would need floating point support and I would be glad to help as I  
am able.  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.  Surely this is already covered in Boost somewhere?

Or please correct me, float fans, if I'm underestimating the problem.

Anyway, I don't think the design would need to be modified in the  
slightest, there just need to be some convenience predicates to plug  
in.  It sounds like Robert is willing to integrate any contributions,  
and I don't have any doubt that they will materialize before the  
library is actually released.

Similarly, the ability to specify multiple constraints is vital, but  
does not need to be directly supported because predicates can be  
combined using STL and better.

I am glad that a method is described for non-integer compile-time  
fixed bounds.  Too bad it takes so much typing, but I don't know how  
that can be avoided without macros. :-p

> - What is your evaluation of the implementation?

I haven't looked at the code, just glanced at the examples.

It is imperative that constrained objects not take any more space than  
the objects, if the predicate and error policy are dataless.  I agree  
with the use case of mapping constrained objects onto memory that  
interfaces with other languages such as C.  The final version should  
have sizeof tests, which should pass on the major compilers.

> - What is your evaluation of the documentation?

Very well written.  But perhaps it doesn't have to be as breezy and  
light after the first page, where that approach is perfect.

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.

Maybe I just prefer a description to a tutorial.  I like the level of  
detail of everything from "Bounding objects with open ranges" on.  All  
of my concerns were alleviated, but only after reading all that ways in.

Each compile time feature should say "this doesn't take any extra  
space", each run-time "this costs X and Y."  Ditto in the examples.

Floating point FUD needs to be excised from the documentation, once  
Robert gets some help implementing that.

> - What is your evaluation of the potential usefulness of the library?

I think this would be very useful to me - it is one of those things  
that is often done ad-hoc but is much better with all the operators  
and with space efficiency guarantees.

> - Did you try to use the library?  With what compiler?  Did you have  
> any
> problems?

No - I see how it should work and trust that it does.  ;-)

> - How much effort did you put into your evaluation? A glance? A quick
> reading? In-depth study?

Followed the discussion and read the documentation closely.  Wrote a  
bit more than I expected to.

> - Are you knowledgeable about the problem domain?

Yep, I've been guilty of ad-hoc implementations, and I once helped  
maintain something similar.

As other people mentioned, I think the author should consider the  
interactions with other libraries such as Probability and Units.  I'm  
not saying that I see any issues, but there might be synergy.

Gordon