Re: [boost] Ranged type mini-library submission

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.
> > http://groups.yahoo.com/group/boost/files/constrained_value/
>
> Not that one, the other sandbox ;-)
>
> http://sourceforge.net/projects/boost-sandbox/

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?

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

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