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?
> value_type temp = x.value();
> 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).
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk