Boost logo

Boost :

From: Rob Stewart (stewart_at_[hidden])
Date: 2005-10-04 13:43:56


From: "Robert Kawulak" <kawulak_at_[hidden]>
> > 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.

I'm sorry. I didn't recognize that you were talking about
individual policies and not the constrained_value type itself.

Still, I don't see the need for what you're discussing for all
types. All you need are compile time constants for the minimum
and maximum and then access those. Yes, that means the code
differs for types that can be used as template arguments and
those that don't (different specializations), but that eliminates
the overhead for what should be a common case.

> 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...
[snip]
> Please do look into the code :) Or better, wait 'till tomorrow or the day
> after, the newest version should be available then.

I looked at it briefly. It doesn't have bearing on this point I
was trying to make. However, having looked at your code now will
help me to avoid suggesting what you're already done (based upon
previous messages in the thread, I had been under the impression
that you had far less implemented than you do).

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