Re: [boost] Ranged type mini-library submission

From: Jeff Garland (jeff_at_[hidden])
Date: 2004-05-16 08:35:34

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

> 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
would it would be it's own little mini-library.
3) Write docs and tests (We can convert some of my date_time tests as a start)
4) Request and complete a fast-track review.

Maybe we should create a place in the boost-sandbox to collaborate on this?

> To Jeff Garland: do you want me to be fully compatible with your existing
> constrained_value type, so that you can link this in without 
> rewriting a thing?

No, not at all.  I'll rework date_time to be compatible.

> /*
>   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.

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

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

>     {
>       // 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?

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

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.

Jeff