Re: [boost] Ranged type mini-library submission

From: christopher diggins (cdiggins_at_[hidden])
Date: 2004-05-16 10:07:22

----- Original Message ----- 
From: "Jeff Garland" <jeff_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Sunday, May 16, 2004 9:35 AM
Subject: Re: [boost] Ranged type mini-library submission

> On Sat, 15 May 2004 22:37:43 -0400, christopher diggins wrote
> > Here is my latest range.hpp file, I should probably change the name
> > back to constrained_value because of the conflict with iterator
> > ranges?
>
> I agree with Pavol, I think constrained_value is a better name for the
simple
> reason that the resulting type doesn't hold a range.  Not to mention that
> range is already very overloaded...

Yes, I am in agreement.

> > I am a first time boost contributor , so I would appreciate
> > comments on my style, and whether this file overextends its intended
> > scope.
>
> Probably more work than you were thinking when you volunteered ;-) So
here's
> the steps we will need to take:
> 1) Agree on a final interfaces / name.
> 2) Decide where this should go in boost.  Could be in utility, but I think
I
> it would be it's own little mini-library.

I agree.

> 3) Write docs and tests (We can convert some of my date_time tests as a
start)

Sounds good.

> 4) Request and complete a fast-track review.
> Maybe we should create a place in the boost-sandbox to collaborate on
this?

Done, I have created a constrained_value folder and uploaded the lastest
version of the file.
http://groups.yahoo.com/group/boost/files/constrained_value/

[snip]
> > /*
> >   range.hpp
> >...snip...
> > // TEMP: my preference is to disallow silent casts to range
> > // the default will have to decided upon by consensus
> > #define BOOST_RANGE_SILENT_CASTS 1
>
> If we are going to allow this option it should be a policy not a macro.
For
> date_time I want the automatic conversion.  But I can imagine that perhaps
in
> the same program I might have another type which I don't want this
behavior.

I agree it would be better as a policy.

> > // you can explicitly turn off range_checking
> > #ifdef BOOST_RANGE_CHECKING_OFF
> > #define BOOST_RANGE_CHECKING_ON 0
> > #else
> > #define BOOST_RANGE_CHECKING_ON 1
> > #endif
>
> Again what happens if I want to change it for some, but not all my
constrained
> types.

On this point, I am not convinced that it is important to make this
specifically a policy. I can only imagine the usage of this kind of switch
for debug versus release code. Switching on a BOOST_RANGE_CHECKING policy
for only some types strikes me as rather pathological.

> > #include <limits>
> >
> > namespace boost
> > {
> >   namespace range
> >   {
> >     using namespace std;
> >
> >     namespace policies
>
> Strikes me as overkill to have another namespace for the policy classes.

Agreed.

> >     {
> >       // some common policies for range types
> >
> >       static inline double less_than(double d) {
> >         return (1.0 - numeric_limits<double>::epsilon()) * d;
> >       }
> >
> >       template<typename T>
> >       struct root {
>                ^^^^
>                cerr_base_policy?

Nice.

> >         typedef T value;
> >         static void on_error(T value, T min, T max) {
> >           cerr << "range violation: " << value << " outside of range
> > " << min << " to " << max << endl;        }      };
> >
> >....snip...
> >
> >     // a simple range class
> >     template<class policy>
> >     class range {
>
> I'm starting to think that Pavel is correct about the orthogonal policies.
> Maybe we need this to be something like:

Me too.

> template<
>   typename ConstraintPolicy,
>   typename ErrorPolicy=default_error_policy,
>   typename ImplicitConversionPolicy=allow_implicit_conversion,
>   typename CheckingPolicy=checking_on>
> class constrained_value
> {
>
> The downside I see here is that errors get much uglier.

I advocate no CheckingPolicy:

 template<
   typename ConstraintPolicy,
   typename ErrorPolicy=default_error_policy,
   typename ImplicitConversionPolicy=allow_implicit_conversion>
 class constrained_value
 { ... }

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