Boost logo

Boost :

From: christopher diggins (cdiggins_at_[hidden])
Date: 2004-05-17 09:51:19

----- Original Message -----
From: "Jeff Garland" <jeff_at_[hidden]>
To: <boost_at_[hidden]>
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.
> >
> Not that one, the other sandbox ;-)

Would it be acceptable that I post on my web site: until we arrive at consensus,
at which i point I submit it to the sandbox?

> > > > // you can explicitly turn off range_checking
> > > > #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
> > 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
> 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
> current macro it ensures that no check is even performed. Replacing the
> 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
> more that min/max checking. To do this and maintain the min/max functions
> 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
> 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

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