Boost logo

Boost :

Subject: Re: [boost] [review][constrained_value] Bounded value
From: Edward Diener (eldiener_at_[hidden])
Date: 2008-12-03 11:01:36

Robert Kawulak wrote:
> Hi Edward,
> 2008/12/3 Edward Diener
>> I believe the bounded objects are actually a subset of a larger concept, which is the set of valid values for an object. Ideally what one could have is a set of bounded values which define the valid values. Each member of the set could be a pair ( or two-element tuple ) defining a lower and upper value inclusive, and of course a single value in the set would have its lower and upper value be the same. In this way one could define, as an example, a constrained object whose integer value could be between 0 and 20 and between 50 and 70. Currently the bounded object concept only allows one "bounds". With the larger concept I mention, a bounded object can have any number of bounds. While the single bounds bounded object can still be supported, I would like to see the constrained value library
> implement a multi-bound concept, in which case the current bounded object concept is just a subset of the multi-bound with a single bound.
> What you ask for can be easily achieved using the current
> implementation. All you have to do is to define a constraint that
> encapsulates several within_bounds predicates, each one responsible
> for one sub-range of the allowed set.

I am hoping that you see a use for multi-bounds constraints without the
need to provide predicates. A predicate is much more flexible but a
non-predictae syntax for multi-bound constraints can be much easier and
quicker for the end user to specify.

> If you don't care about efficiency or want to use
> dynamically-adjustable sets, the task is almost trivial - use
> boost::signal as the constraint type and provide a combiner that
> returns logical alternative of the results. Then add instances of
> within_bounds (or any other predicate) as slots of the signal.

This seems like an overly complicated usage of signals, but of course it
works dynamically. A predicate can also work dynamically. My idea of a
multi-bound constraint is a static constraint like your current bounded

> The built-in support for such multi-range sets could be added to the
> library too, but I wonder if the use case is common enough and I
> should focus on this right now. Anyway, this shuold be easy to achieve
> anytime in the future with no modifications to the current
> implementation.

If you mean that your current functionality need not change, I agree. I
am asking that you consider adding multi-bound constraints and implement
your current single bound constraint as a subset of multi-bound
constraints with a single bound. Thus you would provide greater
flexibility while maintaining what you already have done.

The idea of a multi-bound constraint is really the idea of a set of
valid values for any type. In your current bounded constraint you are
reducing that set of valid values to a single bound, which of course can
be even just a single value if you like. That is valid, and perhaps the
  most common use case, but it is not very flexible IMO. The idea of a
multi-bounded constraint is that the set of valid values should be able
to encompass any value for that type and still be easy for the end user
to denote.

I know your current implementation is being reviewed and should not
change while the review is ongoing so that reviewers will comment on
what you have already done. I only ask that you consider my suggestion
as a more thorough implementation on static constraint values for the

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