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