From: Rob Stewart (stewart_at_[hidden])
Date: 2005-09-29 16:51:22
From: "Robert Kawulak" <kawulak_at_[hidden]>
> > From: Rob Stewart
> > I see what you're doing. Why not:
> > void validate(value_type & value_io);
> > That function can do the validation any way it sees fit and
> > enables the discontinuous ranges you spoke of previously.
> This is exactly the way constrained policies' assign function works (it
> takes the value and decides whether it's correct), but we're one layer below
> :) And here, unfortunately, there are more tests that have to be done, not
> only !(value < min_value || max_value < value):
> in increment: value < max_value
> in decrement: min_value < value
> in wrapping and clipping policies' assign: value < min_value and in other
> place max_value < value
> And I'm afraid it doesn't depend on the design, it's just maths.
I disagree. See below.
If you intend to support discontinuous ranges, then what you've
described won't work. For example, checking whether the new
value is less than the maximum isn't appropriate for incrementing
if the policy is enforcing, say, odd numbers.
One approach is to simply increment the current value and then
call validate(). validate() can decide what to do, including
modifying the value. Unfortunately, for the odd numbers policy,
that's also insufficient, since validate() would need to know
whether to add or subtract one to get to the next odd number in
the direction the caller intended.
So, it seems that the policy must implement validated assignment,
incrementing, and decrementing. You can build the rest of the
behavior on that. Your type can hold the value and rely on the
policy to assign, increment, and decrement.
You can use boost::call_traits to get optimal argument passing
assign(value_type & value_o,
typename boost::call_traits<value_type>::param_type value_i);
The increment() and decrement() functions don't need to worry
decrement(value_type & value_io);
increment(value_type & value_io);
BTW, it might also be important to defer copying to a copying
policy class to account for polymorphic types.
Have I missed something important in the behavior you intend?
-- Rob Stewart stewart_at_[hidden] Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk