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