Boost logo

Boost :

From: Jeff Garland (jeff_at_[hidden])
Date: 2004-05-17 08:02:22

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.

Not that one, the other sandbox ;-)

> > > // 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
> > 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.


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