Boost logo

Boost :

From: Robert Kawulak (kawulak_at_[hidden])
Date: 2005-09-29 17:38:25


> 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,

Boost list run by bdawes at, gregod at, cpdaniel at, john at