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
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
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
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk