----- Original Message ----- From: "Robert Kawulak" <robert.kawulak@gmail.com> To: <boost@lists.boost.org> Sent: Tuesday, December 09, 2008 1:11 AM Subject: Re: [boost] [review][constrained_value] Review of Constrained ValueLibrary begins today
From: Thorsten Ottosen
Yes, it is possible to check the constraint without this. The point is what happens if the constraint is not valid.
? Well, I would expect nothing to happen.
I would expect the error policy to be invoked. If the user decides (by selecting appropriate policy) that an exception should be thrown whenever his operation would cause the value to become invalid, then this should also apply to constraint modification. I would be very surprised if the operation would be simply ignored.
Error policy may need to modify the constraint, so it has to be copied (the argument of change_constraint cannot be modified).
Well, yes, but that justify to copy *also* the value and the error handler?
I suspect yes for the value (to ensure strong exception guarantee), but not necessarily for the error handler.
I also wondering if it is a good idea to let the error_policy change the constraint? Why is that useful?
We need to pass the constraint to the error policy anyway (see below). Letting it modify the constraint is safe and does not cost anything, while this allows for some more sophisticated logic of error handling (bounded object with memory from the docs being an extreme example).
And will it not mean we might pay extra for all the calls to the policy where we do not need to change the constraint in the policy?
In some cases the error policy needs to access the constraint even if it does not need to modify it. For example, the wrap policy needs to query the bounds to perform the modulo arithmetic operations.
Hi, I find that the extreme example "bounded object with memory" is not a good example of constrained_value because not constrained at all. It is the example of what can be done with the current interface but that shouldn't be able to be done with a constrained value. I don't understand why an error policy can modify the value or the constraint. I would prefer an error policy taking only two in-parameters (by value or const&) the new value and the constraint. The wrapping and cliping classes are not exactly constrained values, 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. For the user this do not changes; the classes bounded, wrapping, cliping would provide the same semantics as now. Respect to monitored values I think that it is better to have a separated class. A monitored value do not has an error handling de perse. We can monitor values that are constrained or not. "bounded object with memory" could be better considerd as a monitored value. Best, Vicente