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: Robert Kawulak (robert.kawulak_at_[hidden])
Date: 2008-12-08 19:11:19

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

Best regards,
Robert