On Sun, 16 May 2004 11:07:22 -0400, christopher diggins wrote
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/
Not that one, the other sandbox ;-) http://sourceforge.net/projects/boost-sandbox/
// 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.
Well, if I've got my own class and I'm using the fixed size string class that also uses constrained_value I might accidently turn off the string range checking when I just wanted to turn off my classes range checking. As to using the error_policy to control this, it's not quite the same. With your current macro it ensures that no check is even performed. Replacing the error policy, the code will still do the checking. So if my goal was perfomance optimization than it is lost. I'm intrigued by the suggestion of a validation policy that could implement more that min/max checking. To do this and maintain the min/max functions for the range case we would probably have to do something 'clever' like this: template< class constraints_policy, class error_policy = default_error_policy, bool implicit_conversion_policy = true> class constrained_value : public constraints_policy { allowing the policy to define any client helper functions interfaces. In fact, some classes might want to expose an bool is_valid(value) function to allow checking the value without invoking the error policy. Jeff