Here is my review for the proposed library:
- What is your evaluation of the design?
I think the design is simple, elegant, and allows a lot of flexibility. The only problem I see is that it doesn't address the frequently requested support for floating point constraints. And with that, the problem is not in the implementation-related aspects of the design, but in what the library sets out as requirements for the behavior of the constraint. I think permitting constraints that can "spontaneously" switch from unsatisfied to satisfied (and documenting what that means in terms of guarantees the library makes) would be a good thing. One thing I want to mention is that there is a slightly higher abstraction that this library almost addresses, what can maybe be called "monitored values" - values where you need to do something when the value changes (or is first constructed). In the case of this library, "something" is checking a constraint and calling a policy if the constraint is violated. In other cases, it might be calling a boost.signal, in another, writing to a log. The author might consider (eventually) altering the design of the library to offer this higher level of abstraction, as he already solves the problem of hooking into a value change reasonably well (so, in addition to constrained and bounded classes, offer a monitored class using which constrained is implemented). This would allow much wider use of the library. (I don't know if there are requirements for a "MonitoredValue" library that are significantly different / in addition to what the current libraries, that I'm not thinking of at the moment)
- What is your evaluation of the implementation?
I looked at the implementation of the constrained class, and found it very satisfactory. Well implemented, well documented code that was a pleasure to review.
- What is your evaluation of the documentation?
Great as a tutorial, and great as class / function reference. The only part I found lacking is the discussion of exact requirements on the underlying value type / constraint (my previous posts elaborate on this). Robert - I think the notion of "spontaneous" changes of the constraint extends beyond the floating point case and perhaps be used to discus other "spontaneous" changes or changes beyond the control of whatever the library has control over (like the use_count of a shared_ptr).
- What is your evaluation of the potential usefulness of the library?
Very useful. Beyond the constrained and wrapping built-in types, the documentation suggests some very creative uses of the library, and the flexibility of the library promises a lot more. When it can take advantage of declspec, the usefulness will further increase even more. Lambda might kick it up a notch as well (Robert, in my suggestion to provide syntactic sugar support for the calling of a f(value_type &) function, my unstated point was that f could be any callable - including a lambda expression).
- Did you try to use the library? With what compiler? Did you have any problems?
Nope. No problems :-)
- How much effort did you put into your evaluation? A glance? A quick reading? In-depth study?
I read through the documentation a few times, followed the discussion on the list, and looked at the implementation of the constrained class.
- Are you knowledgeable about the problem domain?
My experience in using functionality related to the library consists of inserting asserts here and there, and manually wrapping values when they need to wrap. I recall plenty of situations where having a library like this would have been wonderful.
Please state in your review, whether you think the library should be accepted as a Boost library.
I believe the library should be accepted. I found the library quite feature-complete for its domain (in reading the docs, every time I found myself thinking "this library should support x", a few paragraphs down I would find out it does), while preserving simplicity and elegance. Some of the things I would definitely like to see in the final version are: * document exact requirements on the value, constraint and policy types, and how they relate to library's guarantees * the library should *legally* allow for a reasonable floating point solution (it would be great if it actually provided one, but allowing one would be good enough for me) * (seconding suggestions by other reviewers): provide tests (including sizeof tests) Nice work, Robert! Stjepan