Re: [boost] [constrained_types] Use cases survey

From: Jeff Garland (jeff_at_[hidden])
Date: 2006-01-18 21:47:05

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