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/tutor... and http://student.agh.edu.pl/~kawulak/constrained_value/reference/classboost_1_... 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