[constrained_types] Use cases survey

Hi, Some time ago there was a discussion on the Constrained Types library. Unfortunately other duties didn't let me work on it for a long time (I apologise for this long break), but recently I started the work again. As a reminder, or short description for those who missed the discussion, there's a brief summary of usage of the library at the end of this message. I need help in determining the most common use cases of the library. Therefore I ask anybody who ever needed such a facility to write what exactly he needed it for, what were his expectations and requirements for functionality and efficiency. In particular, answers for the following questions would be useful (but all opinions and suggestions are valuable): - Is it worth to make different implementation of increment/decrement functions for integer types to make them much more efficient than the generic versions? This needs complicating the design a little bit (but not the usage). OTOH only ++/-- would be optimised, other operators not. So is ++/-- operation actually more common than the others that it's worth it? - Is such a feature likely to be needed: a possibility to select different out-of-bounds policies for both the bounds, e.g. throw when the lower bound is exceeded, clip when upper bound is exceeded. - How often would people need this library to work with types other than integral or floating-point? What kind of types would it be (cheap/expensive to copy)? Any answers, suggestions, advice and questions are welcome. Best regards, Robert EXAMPLES: struct is_even { bool operator()(int v) const { return (v % 2) == 0; } }; constrained<int, is_even>::type even_int(0); even_int += 4; // OK even_int = 1; // error - throws BOOST_DEFINE_VALUE_GENERATOR(abc_type, std::string, "abc"); BOOST_DEFINE_VALUE_GENERATOR(xyz_type, std::string, "xyz"); bounded<std::string, abc_type, xyz_type>::type my_string; // my_string == "abc" s = "x"; // OK s += "zz"; // throws - "xzz" is not within the range bounded_int<int, 0, 5, error::do_nothing>::type my_int; // my_int == 0 my_int++; // OK my_int *= 100; // invalid operation ignored, still my_int == 1 wrapping_int<unsigned_int, 5, 10>::type wraps; // wraps == 5 wraps--; // wraps == 10 wraps += 2; // wraps == 6 saturating<std::string, abc_type, xyz_type>::type clips; // clips == "abc" clips = "z"; // clips == "xyz" - value clipped to the upper bound These are just the simpliest examples. Other features are: - policy-based design allowing customizations like different constraint, error or out-of-bounds policy classes, - any of the bounds may be excluded from the allowed set of values (open ranges), - bounds may be adjustable at run-time or defined at compile-time, - and some more I can't remember at the moment ;-) ------------------------------------------------------------------- Zmyslowa czerwien... >>> http://link.interia.pl/f18f0

Robert Kawulak wrote:
Hi,
Some time ago there was a discussion on the Constrained Types library. Unfortunately other duties didn't let me work on it for a long time (I apologise for this long break), but recently I started the work again. As a reminder, or short description for those who missed the discussion, there's a brief summary of usage of the library at the end of this message.
I need help in determining the most common use cases of the library. Therefore I ask anybody who ever needed such a facility to write what exactly he needed it for, what were his expectations and requirements for functionality and efficiency. In particular, answers for the following questions would be useful (but all opinions and suggestions are valuable):
- Is it worth to make different implementation of increment/decrement functions for integer types to make them much more efficient than the generic versions? This needs complicating the design a little bit (but not the usage). OTOH only ++/-- would be optimised, other operators not. So is ++/-- operation actually more common than the others that it's worth it?
No.
- Is such a feature likely to be needed: a possibility to select different out-of-bounds policies for both the bounds, e.g. throw when the lower bound is exceeded, clip when upper bound is exceeded.
No.
- How often would people need this library to work with types other than integral or floating-point? What kind of types would it be (cheap/expensive to copy)?
My usage would be integral-like types.

Robert Kawulak wrote:
I need help in determining the most common use cases of the library. Therefore I ask anybody who ever needed such a facility to write what exactly he needed it for, what were his expectations and requirements for functionality and efficiency.
My use case is fairly simple: I have a constrained, contiguous integer range and a second set of integers of the same size that are constrained but not contiguous. The latter set is a unique "geographical" descriptor for an element of a particle detector, where the integer carries human readable location information. The former is a corresponding "serial number" in a contiguous range (useful for making plots and addressing arrays). Some operations are efficient in one of these spaces and not the other, and since I will have many terabytes of data at the end of the day, it would be nice if operations were as efficient as bare integers, and conversions between these types need to be fast. Operations should be transparently integer like to the extent possible.
So is ++/-- operation actually more common than the others that it's worth it?
No
a possibility to select different out-of-bounds policies for both the bounds,
No.
- How often would people need this library to work with types other than integral or floating-point? What kind of types would it be (cheap/expensive to copy)?
Not at all at this time -- ------------------------------------------------------------------------------- Kevin Lynch voice: (617) 353-6025 Physics Department Fax: (617) 353-9393 Boston University office: PRB-361 590 Commonwealth Ave. e-mail: krlynch@bu.edu Boston, MA 02215 USA http://budoe.bu.edu/~krlynch -------------------------------------------------------------------------------

| -----Original Message----- | From: boost-bounces@lists.boost.org | [mailto:boost-bounces@lists.boost.org] On Behalf Of Robert Kawulak | Sent: 18 January 2006 13:09 | To: boost@lists.boost.org | Subject: [boost] [constrained_types] Use cases survey | | Some time ago there was a discussion on the Constrained Types | library. Unfortunately other duties didn't let me work on it for | a long time (I apologise for this long break), but recently I | started the work again. Good! Boost needs them. | - Is it worth to make different implementation of | increment/decrement functions for integer types to make them much | more efficient than the generic versions? I doubt it. | - Is such a feature likely to be needed: a possibility to select | different out-of-bounds policies for both the bounds, e.g. throw | when the lower bound is exceeded, clip when upper bound is | exceeded. Yes, definitely would add value, but sounds expensive. | - How often would people need this library to work with types | other than integral or floating-point? What kind of types would | it be (cheap/expensive to copy)? My guess if that builtin types will be by far the most common, but if UDTs are possible at no extra cost ... complex? interval? tuples? Paul -- Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB Phone and SMS text +44 1539 561830, Mobile and SMS text +44 7714 330204 mailto: pbristow@hetp.u-net.com http://www.hetp.u-net.com/index.html http://www.hetp.u-net.com/Paul%20A%20Bristow%20info.html

On Wed, 18 Jan 2006 14:08:36 +0100, Robert Kawulak wrote
Hi,
Some time ago there was a discussion on the Constrained Types library. Unfortunately other duties didn't let me work on it for a long time (I apologise for this long break), but recently I started the work again. As a reminder, or short description for those who missed the discussion, there's a brief summary of usage of the library at the end of this message.
I need help in determining the most common use cases of the library. Therefore I ask anybody who ever needed such a facility to write what exactly he needed it for, what were his expectations and requirements for functionality and efficiency. In particular, answers for the following questions would be useful (but all opinions and suggestions are valuable):
Well, as you're already aware there are versions of these things that are used in the implementation of date-time. The basic requirements are/were: For range integral types: 1) Convertable from integral type (always an integer type) 2) Policy-based error handling -- month and day_of_month throw different exceptions (bad_month and bad_day) when the value is out of range. 3) Need static 'traits functions' to get minimum and maximum values for ranges. This is so if you are parsing you can use the type to check before construction if you want. 4) In date-time the range types don't support addition/subtraction etc. The way they are used it wasn't needed. 5) Method to get the underlying type out. For wrapping types 1) Convertable from integral type (always an integer type again) 2) These need special addition/subtraction with remainder/overflow. So, for example, take the following wrapping_int<integer, 1, 7> wi; //wi == 1; wi.add(8); // wi == 2 -- returns 1 (wrapped once) wi.subtract(8); //wi == 1 -- returns 1 (wrapped once) In date-time algorithms I need the wrapping count in some algorithms. I've also used this in the design of a circular queue to allow indexing to wrap correctly. 3) Need static 'traits functions' to get minimum and maximum values for ranges. 4) Method to get the underlying type out.
- Is it worth to make different implementation of increment/decrement functions for integer types to make them much more efficient than the generic versions? This needs complicating the design a little bit (but not the usage). OTOH only ++/-- would be optimised, other operators not. So is ++/-- operation actually more common than the others that it's worth it?
I don't think so.
- Is such a feature likely to be needed: a possibility to select different out-of-bounds policies for both the bounds, e.g. throw when the lower bound is exceeded, clip when upper bound is exceeded.
Never needed this, but if the policy design should allow it.
- How often would people need this library to work with types other than integral or floating-point? What kind of types would it be (cheap/expensive to copy)?
Never.
Any answers, suggestions, advice and questions are welcome.
I'm also interested in your string stuff -- is there a current draft of stuff posted somewhere? Also, I'd be willing at some point to experiment with replacing my date-time implementations with yours -- it would be an easy way to test that I got all the use cases right ;-) Jeff

Hi,
From: Jeff Garland
Well, as you're already aware there are versions of these things that are used in the implementation of date-time. The basic requirements are/were:
[snip reqirements] Thanks! I've taken a glance at them and it seems the library already fulfills all but...
2) These need special addition/subtraction with remainder/overflow. So, for example, take the following wrapping_int<integer, 1, 7> wi; //wi == 1; wi.add(8); // wi == 2 -- returns 1 (wrapped once) wi.subtract(8); //wi == 1 -- returns 1 (wrapped once)
Well, this needs thinking over...
I'm also interested in your string stuff -- is there a current draft of stuff posted somewhere?
Not yet, I'll do this as soon as the code is suitable for posting ;-)
Also, I'd be willing at some point to experiment with replacing my date-time implementations with yours -- it would be an easy way to test that I got all the use cases right ;-)
That's a great idea! Best regards, Robert
participants (6)
-
Jeff Garland
-
Kevin Lynch
-
Neal Becker
-
Paul A Bristow
-
Robert Kawulak
-
Robert Kawulak