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

Subject: Re: [boost] [review][constrained_value] Review of Constrained Value Library begins today
From: Thorsten Ottosen (thorsten.ottosen_at_[hidden])
Date: 2008-12-09 07:10:27

Robert Kawulak skrev:
>> 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.

I was unintentionally unclear. I meant that the held value should be 
unchanged.

>>> 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.

This seems a little ad hoc to me. What are the requirements of the 
contraint? Is it unrealistic to demand that it has a no-throw swap?
If not, then do it, and give change_contraint the strong guarantee as 
one would expect.

>> 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.

I guess my concern here is that the error policy is more than just an 
error policy. This suggest that another *orthogonal* concept is hidden 
in there somewhere.

Thorsten