From: "Robert Kawulak" <kawulak@student.agh.edu.pl>
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@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;