Boost logo

Boost :

Subject: Re: [boost] [review][constrained_value] Review of Constrained Value Library begins today
From: Thorsten Ottosen (thorsten.ottosen_at_[hidden])
Date: 2008-12-08 15:53:01

Robert Kawulak skrev:
>> From: Thorsten Ottosen
>>>> this seems *very inefficient* compared to only changing
>> the constraint.
>>> You can't simply change the constraint if the current value does not
>>> conform to it.You have to check that and eventually copy
>> the value and
>>> the constraint, call the error policy for them and assign them back.
>>> In most common cases this seems not much more efficient than copying
>>> the whole object and swapping it (considering the typical case when
>>> one or both of the policies are empty or have trivial copy).
>>> Having said that, I agree with you at this point -- implementing
>>> change_constraint as a member might allow for more efficient
>>> implementation for some cases. This is an argument that
>> might convince
>>> me to make it a member and I will investigate this possibility.
>> It seems to me that it must be possible to check the new constraint
>> without creating a new object.
> 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.

> 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 also wondering if it is a good idea to let the error_policy change the
constraint? Why is that useful? 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?


Boost list run by bdawes at, gregod at, cpdaniel at, john at