Hi Stjepan, You have a very nice gift of catching all possible inaccuracies. :D
From: Stjepan Rajko "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 &.
Of course you're right, this is an informal definition and expresses rather a desire, a design goal, which of course cannot be fully achieved due to the language limitations.
Could you provide a slightly more precise explanation?
I'll try. Some hints? ;-)
*((iter++).value()) ... so I assume you can't do *(iter++). (if so, why not?)
No, you can't. This is because (iter++) is of type constrained<...>, and while it is implicitly convertible to the underlying iterator type, it doesn't have the * operator (actually, it doesn't have any non-mutating operators overloaded). It couldn't have the * operator, because in general case it couldn't know what should be the return type.
"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"?)
Again, you got me here. Maybe "it can only be given values..."? My intention was to stress the fact, that the constraint checking happens each time the object is actually modified (and it is usually modified through the assignment operators, although not exclusively).
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?
No. From the perspective of a constrained object's user it's true that the constraint cannot be accessed directly for modification in any way. OTOH the error policy is allowed to modify anything within the constrained object when invoked (as long as the value remains constraint-conforming). This is what the policy in the example does.
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?
The constraint may depend on any state, mutable or not -- it's the constrained object's task to make sure that the value is immutable for the "outside world" (and it does so by providing only value access methods returning a const reference). Thanks for feedback, Robert