Boost logo

Boost :

From: Robert Kawulak (kawulak_at_[hidden])
Date: 2005-09-27 14:30:34


>From: Rob Stewart
> It sounds like--I've not looked at either class to
> know whether this is reasonable--wrapping_int's behavior could be
> subsumed by constrained_value. That is, Robert's class could
> determine the new value to store based upon calling a policy
> function. If that function determines that the new value is out
> of range, then it can wrap the value or otherwise adjust it, or
> it can signal an error.

This is exactly how it works :)

> Such an approach could actually permit incrementing a
> constrained_value that only permits odd numbers. That is,
> incrementing would increment to the next odd number. (To support
> that would require a fatter policy interface, I expect, so I'm
> not saying it would necessarily be a good idea.)

The policy interface is indeed fatter, it contains the following five
functions (the version I'm currently working on, not published yet):
  initialize() - returns a value used to default-initialize a constrained
  is_valid_value(value) - returns false if assignment of the value to
    a constrained object would be an error (used to verify if a value input
    from a stream is correct);
  assign(variable, new_value) - performs assignment of new_value to the
    variable holding the value of a constrained object;
  increment(variable) - increments the variable holding the value of
    a constrained object;
  decrement(variable) - decrements the variable holding the value of
    a constrained object.

increment() and decrement() are added for efficiency reasons (in case of
bounded types you need only one comparison and increment/decrement instead
of addition, two comparisons and assignment). However, there are no policy
functions for +=, *= etc. - this would make the whole constrained types
thing too messy. Increment and decrement are just so common, and the
efficiency gain seems to be significant enough, that I've decided to put
them there.

BTW in the current version I've changed the name of basic_bounded template
to constrained_type (I don't like constrained_value name which may be
misleading, because it's a type of values rather than a value itself), and
named the library constrained_types. I'm refactoring the design a little,
adding some additional functionality and hope to publish it soon, and maybe
submit for a formal review if people like it :)

Best regards,

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