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
>>> Error policy may need to modify the
>>> constraint, so it has to be copied (the argument of
>> change_constraint cannot be
>> 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.