Re: [boost] [review][constrained_value] Review ofConstrainedValueLibrary begins today

Subject: Re: [boost] [review][constrained_value] Review ofConstrainedValueLibrary begins today
From: Robert Kawulak (robert.kawulak_at_[hidden])
Date: 2008-12-04 19:32:24

> From: Stjepan Rajko
> On Tue, Dec 2, 2008 at 6:53 PM, Robert Kawulak 
> <robert.kawulak_at_[hidden]> wrote:
> >
> > The rule is that the
> > result of the constraint invocation for the value must 
> always be identical as
> > long as you don't access either of them as non-const.
[...]
> Perhaps a concise way to describe a requirement (addressing both these
> cases, as well as the const mutable problem) is to say that the
> constraint must depend only on what is mutable by expressions that
> require a non-const reference to the underlying object?

Not exactly. Constraint may depend on its own state too, but again it's not an
allowed situation if constraint may be somehow altered by a const reference and
change its judgement for unchanged value.

> Are there also requirements that the way in which the underlying
> object is CopyConstructable and/or Swappable maintain the constraint?

Implicit, yes.

> value_type temp = x.value();
> f(temp);
> x = temp;
> 
> If this is a frequent use case, I'd prefer to be able to write
> call_using_copy(f, x);  or call_using_copy(&f, x); or 
> something like that.

So is it a frequent use case? I have no idea. I never needed this.

> I just looked at the code (it's very nice to look at!), and am trying
> to get a grasp on the policy design.  At first I had some doubts about
> it, but am getting more and more convinced that you have the design
> right.  This is what I understand:
>  * the policy gets called iff there is a problem
>  * a problem happens when the underlying object is constructed with an
> invalid value, in which case the policy gets called with that invalid
> value as both the first and second parameters
>  * a problem happens when an invalid value wants to be assigned to the
> underlying object, in which case the policy gets called with the
> current (valid) value as the first argument, and the new (invalid)
> value as the second argument
>  * the first argument must satisfy the constraint when/if the 
> policy returns.

Exactly. As to the last point -- more generally, the first argument must satisfy
the third argument (which can also be modified by the policy).

Regards,
Robert