|
Boost : |
From: Robert Kawulak (kawulak_at_[hidden])
Date: 2005-09-29 17:38:25
Hi,
> From: Rob Stewart
> > 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.
Oh, but I was talking only about how bounded policies work! Of course I know
that the behaviour for, say, odd policy would be different, and
discontinuous ranges ARE supported, I just wasn't talking about them.
> 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.
And that's exactly how it's done, but you still haven't look into the code,
have you? ;-) This discussion seems to be pointless unless you do so...
> You can use boost::call_traits to get optimal argument passing
> for assign():
>
> void
> 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
> about that:
>
> void
> decrement(value_type & value_io);
>
> void
> increment(value_type & value_io);
Please do look into the code :) Or better, wait 'till tomorrow or the day
after, the newest version should be available then.
Best regards,
Robert
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk