From: vicente.botet
And I see no reason to disallow changing the constraint too. If something: * is not potentially dangerous, * costs nothing, * does not add extra complexity for the normal usage, * creates opportunity to use the library in some new, creative way, if somebody wishes to, then why should it be banned?
Well the error_policy function follows this prototype template <typename V, typename C> void operator () (const V &, const V &, const C &) const; while this one could be enough template <typename V> void operator () (const V &) const;
The question that I answered here was why error policy can modify the constraint, while now you're jumping to why error policy takes the constraint as argument. This has already been answered in my earlier post.
I'm realy get convainced that the base type od the constrained class should be monitored and the prototype for a Monitor function should be template <typename V> void operator () (V &) const;
Did you do any research of possible use cases? If I were to design a monitored value class, I'd consider passing both the old and the new value to allow for a more general usage. For example, the monitor function would be able to log somewhere how much the value has changed or prevent invalid state transition in a model of a finite state machine.
We see that the classes clipping and wrapping can be implemented in a more efficient way by defining a Monitor than defining a Constraint and an ErrorPolicy.
Maybe. But given optimisation capabilities of compilers, I would say: not much more. I have been compiling code snippets using wrapping<int> (with dynamic bounds) to assembly code and the result was as if the code had been written by hand in an optimal way.
The wrapping and cliping classes are not exactly constrained values
It depends how you define constrained value. The design of this library assumes that constrained object is an object with value conforming to a specified constraint (so constrained object guarantees that its value belongs to the specified subset of values of the underlying type). Can you show that this definition is inappropriate or that wrapping/clipping objects don't fit to it? The fact that a value is constrained is a contract, and throwing or adjusting the value are examples of methods (policies) guaranteeing this contract.
, they are adapting a value of a type to a constrained
value. So I would prefer to have a different class for them taking a constraint adaptor that would take the value by reference and adapt it to the constraint.
So, having the adaptor, why its underlying value should be a constrained object at all?
I have no said that.
I thought this is what you meant by saying: "they are adapting a value of a type to a constrained value". Best regards, Robert