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