----- Original Message ----- From: "Jeff Garland" <jeff@crystalclearsoftware.com> To: <boost@lists.boost.org> 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)
4) Request and complete a fast-track review. Maybe we should create a place in the boost-sandbox to collaborate on
Sounds good. 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