----- Original Message ----- From: "Jeff Garland" <jeff@crystalclearsoftware.com> To: <boost@lists.boost.org> Sent: Monday, May 17, 2004 9:02 AM Subject: Re: [boost] Ranged type mini-library submission
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 ;-)
// 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
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
Would it be acceptable that I post on my web site: http://www.cdiggins.com/constrained_value.hpp until we arrive at consensus, at which i point I submit it to the sandbox? policy 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.
Yes it is agreed then, the macro goes.
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.
I too like the idea of a validation policy. You propose an interesting technique but I am not convinced it is the best option for what we want. If constraints_policy does the validation then the error handling policy could just more easily be passed as an argument to the constraints policy. This leaves us with: template< class constraints_policy, bool implicit_conversion_policy = true> class constrained_value { ... } This seems to be the simplest possible thing that will work. Christopher Diggins http://www.cdiggins.com http://www.heron-language.com