Re: [boost] Bounded types (or maybe not 'bounded' anymore? ;-)

From: Jeff Garland (jeff_at_[hidden])
Date: 2005-09-25 18:43:07

On Mon, 26 Sep 2005 01:02:25 +0200, Robert Kawulak wrote
> Hi, 
> 
> > Restricted is ok, but I like constrained better.  Please see:
> > 
> > http://www.boost.org/doc/html/constrained_value.html
> > http://www.boost.org/boost/date_time/constrained_value.hpp
> > http://www.artima.com/weblogs/viewpost.jsp?thread=79470
> > 
> > Jeff
> 
> Thank you very much for the links, they inspired me to think deeply about
> the design of my class once again :). What I meant to create was pretty
> similar to constrained_value, only more complex, more general and 
> maybe a little more efficient.

Good -- it seemed like alot of the thinking in this thread (which I've really
only been skimming, so perhaps this is unfair) hadn't been considering prior
art.  Just so you know, it's my feeling that the 'range constraint' is the
most frequent and most of the more complicated cases you can imagine don't
come up that much in practice.  I'm not even sure it's really worth
supporting. The most important thing is to allow customization of the error
handling and set it up so the details of the constraint violation can (eg: min
or max) can be determined.  Again I've been skimming so I don't know if your
code does this or not.

One other thought.  The constrained value type fits into a 'value programming'
classification that eventually I'd like to see expanded in boost.  Some other
parts of this include wrapping_int which has a range and wraps around when you
do math with it, integer_adapters which adds infinites and null values to
ints.  I have a "super enumeration class" (never posted) that fits into this
category and I know a couple others have been proposed on the list which is a
related concept. If you haven't already have a look at 

http://www.two-sdg.demon.co.uk/curbralan/papers/ObjectsOfValue.pdf

for some broader thoughts on this subject.  Anyway, I've seen using these
small value types really cleanup what would otherwise be ugly and messy code.

> BTW, constrained_value of Christofer Diggins has at least one 'bug' -
>  it has a default constructor which default-initialises the value, 
> and doesn't check if this default value conforms to the constraints. 

That's not good.  I guess you'd need need one of the policies to specify the
default value if it is allowed.  In the date-time constrained_value there is
no default constructor as I recall.

> I also believe, that it'd be better to supply operator const value() 
> than operator value() - this conversion is implicit so the const 
> version would be safer.

Yep.

Jeff