Boost logo

Boost :

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
> // TEMP: my preference is to disallow silent casts to range
> // the default will have to decided upon by consensus

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
> #else
> #endif

Again what happens if I want to change it for some, but not all my constrained

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

> typedef T value;
> static void on_error(T value, T min, T max) {
> cerr << "range violation: " << value << " outside of range
> " << min << " to " << max << endl; } };
> // 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:

  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.


Boost list run by bdawes at, gregod at, cpdaniel at, john at