Re: [boost] [review][constrained_value] Review of Constrained ValueLibrary begins today

Subject: Re: [boost] [review][constrained_value] Review of Constrained ValueLibrary begins today
From: vicente.botet (vicente.botet_at_[hidden])
Date: 2008-12-09 01:26:01

----- Original Message ----- 
From: "Robert Kawulak" <robert.kawulak_at_[hidden]>
To: <boost_at_[hidden]>
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