[constrained_value] Formal review request

Dear Boosters, I'm glad to say the Boost Constrained Value library is finally ready for a formal review. To remind what this library is about, an excerpt from the motivation section of the documentation is attached at the bottom of this message. Jeff, you volunteered to be the review manager - is your proposition still up to date? If so, I'd be thankful if you could do the work. ;-) The code and documentation can be downloaded here: http://rk.go.pl/f/constrained_value.zip The documentation is also available online here: http://rk.go.pl/r/constrained_value The only thing that's missing is test programs - I will try to add them during/after the review. The changes made since previous version: - rewritten the documentation at some points and added tutorial, - no more value generators - direct types or MPL integral constants are used instead, - bounded types use bounds exclusion instead of inclusion (so bounds are included by default in all cases), - changed order and default values of some of template parameters, - removed throw_verbose_exception error policy, - made other minor fixes and improvements. As always, feedback is welcome. Best regards, Robert Kawulak FROM THE MOTIVATION SECTION OF THE DOCUMENTATION: The Boost Constrained Value library contains class templates useful for creating constrained objects. A simple example is an object representing an hour of a day, for which only integers from the range [0, 23] are valid values: bounded_int<int, 0, 23>::type hour; hour = 20; // OK hour = 26; // exception! Behavior in case of assignment of an invalid value can be customized. For instance, instead of throwing an exception as in the example above, the value may be adjusted to meet the constraint: wrapping_int<int, 0, 255>::type buffer_index; buffer_index = 257; // OK: adjusts the value to fit in the range by wrapping it assert( buffer_index == 1 ); The library doesn't focus only on bounded objects as in the examples above -- virtually any constraint can be imposed by using a predicate: // constraint (a predicate) struct is_odd { bool operator () (int i) const { return (i % 2) != 0; } }; // and the usage is as simple as: constrained<int, is_odd> odd_int = 1; odd_int += 2; // OK ++odd_int; // exception! The library has a policy-based design to allow for flexibility in defining constraints and behavior in case of assignment of invalid values. Policies may be configured at compile-time for maximum efficiency or may be changeable at runtime if such dynamic functionality is needed.

Hi Robert, I will add the Constrained Value library to the review queue, with Jeff as review manager. The two of you should coordinate on when you would like the review to happen. Cheers, ron On Jun 20, 2008, at 3:57 AM, Robert Kawulak wrote:
Dear Boosters,
I'm glad to say the Boost Constrained Value library is finally ready for a formal review. To remind what this library is about, an excerpt from the motivation section of the documentation is attached at the bottom of this message.
Jeff, you volunteered to be the review manager - is your proposition still up to date? If so, I'd be thankful if you could do the work. ;-)

can we create a saturating int with only lower bound set and upper bound is infinite, like saturating_int<int, 1>::type ImageBoundary; ~--~--~--~--~--~--~--~--~--~--~--~--~--~--~--~--~--~--~--~--~--~--~--~--~ "İyi bir seyyahın belirli bir planı yoktur, ulaşmak gibi bir amacı da." "A good traveller has no fixed plans, and is not intent on arriving." On Wed, Jun 25, 2008 at 5:53 PM, Ronald Garcia <garcia@cs.indiana.edu> wrote:
Hi Robert,
I will add the Constrained Value library to the review queue, with Jeff as review manager. The two of you should coordinate on when you would like the review to happen.
Cheers, ron
On Jun 20, 2008, at 3:57 AM, Robert Kawulak wrote:
Dear Boosters,
I'm glad to say the Boost Constrained Value library is finally ready for a formal review. To remind what this library is about, an excerpt from the motivation section of the documentation is attached at the bottom of this message.
Jeff, you volunteered to be the review manager - is your proposition still up to date? If so, I'd be thankful if you could do the work. ;-)
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Hi,
From: utku
can we create a saturating int with only lower bound set and upper bound is infinite, like
saturating_int<int, 1>::type ImageBoundary;
Yes, you can simply write: saturating_int<int, 1, boost::integer_traits<int>::const_max>::type ImageBoundary; Since no int is greater than const_max, the upper bound will never be used for saturation (and I bet compilers will easily optimise the code eliminating the comparison with the upper bound). Best regards, Robert

Robert Kawulak wrote:
Hi,
From: utku
can we create a saturating int with only lower bound set and upper bound is infinite, like
saturating_int<int, 1>::type ImageBoundary;
Yes, you can simply write:
saturating_int<int, 1, boost::integer_traits<int>::const_max>::type ImageBoundary;
Since no int is greater than const_max, the upper bound will never be used for saturation (and I bet compilers will easily optimise the code eliminating the comparison with the upper bound).
Would it be possible for you to make that a default parameter for the class? That would really improve usability for this use-case. Joe Gottman

Hi,
From: Joe Gottman
Robert Kawulak wrote:
Hi,
From: utku
can we create a saturating int with only lower bound set and upper bound is infinite, like
saturating_int<int, 1>::type ImageBoundary;
Yes, you can simply write:
saturating_int<int, 1, boost::integer_traits<int>::const_max>::type ImageBoundary;
Since no int is greater than const_max, the upper bound will never be used for saturation (and I bet compilers will easily optimise the code eliminating the comparison with the upper bound).
Would it be possible for you to make that a default parameter for the class? That would really improve usability for this use-case.
I don't know if it's a good idea to make the default for this special use case - if I'd see something like saturating_int<int, 1>::type, probably it wouldn't be easy for me to guess if it saturates below or over 1. Maybe another set of aliases with more descriptive names would be better? Like: lower_saturating_int<int, 0>::type - clips values less than 0 upper_saturating_int<int, 0>::type - clips values greater than 0 I'm not sure if those names are good enough either... BTW, is this a common use case in some areas? Best regards, Robert
participants (4)
-
Joe Gottman
-
Robert Kawulak
-
Ronald Garcia
-
utku