Re: [boost] Re: Ranged type mini-library submission

From: christopher diggins (cdiggins_at_[hidden])
Date: 2004-05-17 09:38:21

----- Original Message ----- 
From: "Robert Bell" <belvis_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Sunday, May 16, 2004 7:02 PM
Subject: [boost] Re: Ranged type mini-library submission

> christopher diggins wrote:
> >>should this be using numeric_limits<T>::epsilon() (instead of
DBL_EPSILON)
> >>and would that even work for numbers larger than 2.0?
> >
> >
> > Good point, I am working on fixing that.
>
> This doesn't seem like the best way to get this result. If I try to
> create an interval of [0, 1e100), this won't work; 1e100 -
> numeric_limits<T>::epsilon() is very likely to be 1e100, which would let
> me (incorrectly) assign 1e100 to such a constrained value.
>
> It seems to me that whether one end of an interval is open or closed
> corresponds to whether or not you use strict less-than/greater than, or
> less-than-or-equal/greater-than-or-equal. A value is in [0, 1e100) if
>
> (0 <= value && value < 1e100)
>
> is true. This is correct regardless of the type of value (assuming it
> provides < and <=, which is reasonable to assume for any type you're
> going to build an interval out of).
>
> To implement this, you could introduce another policy that controls how
> the min and max values are compared to the value.
>
> // prototype of the interval policy:
> template<typename T>
> struct interval_policy {
>     static bool check_min(T value, T min);
>     static bool check_max(T value, T max);
> };
>
> // concrete cases:
> template<typename T>
> struct open_policy {
>     static bool check_min(T value, T min) { return value > min; }
>     static bool check_max(T value, T max) { return value < max; }
> };
>
> template<typename T>
> struct closed_policy {
>     static bool check_min(T value, T min) { return value >= min; }
>     static bool check_max(T value, T max) { return value <= max; }
> };
>
> You let the user specify an interval policy for the upper part and the
> lower part of the interval. Then your error check becomes:
>
>     if (!lower_policy::check_min(value, min())) {
>        // min_violation handler here
>     }
>     if (!upper_policy::check_max(value, max())) {
>        // max_violation handler here
>     }
>
> (A variation might revolve around letting a user specify std::less or
> std::less_equal.)
>
> But doing it this way we introduce two new polic arguments; maybe that's
> not so good.
>
> Another approach might be to change the definition of the
> constraints_policy itself so that it is responsible for the validation.
> You give it a member function called validate() which is expected to
> return true if the value is good, false otherwise. A variation on this
> approach would have it a return a value. The advantage of this variation
> would be that a policy could change a value to something legal and
> return it. For example, I could specify the interval [0, 10], and set it
> up so that if I assigned 11 to a variable of this type, it could clamp
> it to 10 rather than signal an error. (So far, the option to change an
> illegal value to a legal one and continue has not been mentioned, but it
> seems like a reasonable thing to want to do.)
>
> This approach also allows things that weren't part of the original idea,
> so I'm not sure what you'd think of them. For example, I could create a
> policy that allows even numbers only (not sure why I'd want that, but it
> would be possible).
>
> What do you think?
>
> Bob

You bring up an excellent point. I like the idea of having the policy do the
verification itself.

Christopher Diggins
http://www.cdiggins.com
http://www.heron-language.com