Re: [boost] [Review] ITL review starts today, February 18th

Subject: Re: [boost] [Review] ITL review starts today, February 18th
From: John Bytheway (jbytheway+boost_at_[hidden])
Date: 2010-02-23 14:31:02

Jeff Flinn wrote:
<snip>
> Yes, I agree bound_type is an important concept. The question is whether
> an interval's bound_type should be a runtime data member or part of the
> interval's type. My inclination is the latter. I would think that the
> problem domain would be dealing with only intervals of a particular
> bound_type, hence a container would be templated on the bound_type in
> addition to the domain and co domain types. If there is a need for mixed
> bound_types within a single problem domain, there could be a run time
> bound_type. But I shouldn't have to pay those run time costs if my
> problem domain doesn't need to.

The (under development) ConstrainedValue library has a clever scheme to
support compile-time or run-time through the same interface.  See

http://student.agh.edu.pl/~kawulak/constrained_value/constrained_value/tutorial.html

and

http://student.agh.edu.pl/~kawulak/constrained_value/reference/classboost_1_1constrained__value_1_1within__bounds.html

The bound can be either an mpl::int_ which stores it at compile time or
an int which stores it at runtime.  Because an mpl::int_ implicitly
converts to an int the same code can be used for both, and
compressed_pair means the mpl version uses no space.

You could do something similar by using either the enumeration type or
an mpl wrapper around a particular value thereof.

John Bytheway