On Mon, Dec 1, 2008 at 5:30 AM, Jeff Garland
The review of the Robert Kawulak's Constrained Value library begins today December 1, 2008, and will end on December 10th -- I will be the review manager. Please post reviews to the developer list.
Hi Robert, This seems like a very useful library, and after a cursory look of the documentation I feel that it has nicely well-rounded functionality. I have a couple of questions at this point (mostly extreme nit-picks about things that confused me when trying to think about how all I could use this library). In the basic definitions you have: "Constrained object is a wrapper for another object. It can be used just like the underlying object, with one exception: it can be assigned only a value which conforms to a specified constraint." ... "It can be used just like the underlying object": I have a suspicion that it can't be used "just like" the underlying object in all circumstances :-) I assume you can't call member functions of the underlying object if it's a class type (with the same syntax), or provide a constrained<int> as an argument to a function that takes an int &. Could you provide a slightly more precise explanation? The examples I looked at all use the constrained object in operator expressions. Is it that it can be used just like the underlying object in (most) operator expressions? In your wrapping iterator example you have: *((iter++).value()) ... so I assume you can't do *(iter++). (if so, why not?) "it can be assigned only a value which conforms to a specified constraint": when you say assigned, I'm thinking of the assignment operator, but you constrain more than that. Perhaps there is a more inclusive way of saying this? (maybe "it can only hold values which conform to a specified constraint"?) In your example "Object remembering its past extreme values", the policy is changing the constraint object directly. But, in your tutorial, you have: "Constraint of a constrained object cannot be accessed directly for modification, because the underlying value could become invalid according to the modified constraint. Therefore the constraint of a constrained object is immutable and change_constraint() function has to be used in order to modify the constraint. ..." Is the example violating how the library should be used? The value() function returns the underlying object by const &... so, I'm assuming that the constraint is not allowed to depend on any mutable parts of the underlying object's state? Thanks, Stjepan