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