[boost] [constrained_types] Here it is :D

From: Robert Kawulak (kawulak_at_[hidden])
Date: 2005-10-03 13:47:24

Hi, 

  The new, almost finished constrained_types library is here:
http://student.agh.edu.pl/~kawulak/ct.zip. It's later than I promised, but
recently I didn't have much time and I just wanted to polish it before
publishing. I successfully compiled it with the following compilers:
gcc 4.0.0 (Djgpp)
gcc 3.4.2 (MinGW)
Borland C++ 5.6.4
Microsoft C++ 13.10.3077
Digital Mars 8.45c

> From: Paul A Bristow
> | > If you call it the "Constrained Types" library, and use the
> | > namespace "constrained_types," does "constrained" for the type
> | > name fit with Boost prior art and intention?  Those names sound a
> | > lot better, so that may be sufficient justification, but I don't
> | > want to presume this approach is acceptable to Boost as a whole.
> | 
> | For me the latters also sound better, what do you people think?
> 
> I think these short, unabbreviated but accurate names sound good,
> and fit with established names.

I didn't change the name of constrained_type template to constrained yet,
but if this shorter form is OK then I'll do this before next update.

> Also I am sure I am not alone in being encouraged by the 
> progress so far -
> but Boost needs this to be _FINISHED_ including the 
> documentation (including
> acknowledgement to the several previous but not quite finished
> contributions, and rationale), tests and EXAMPLES of use.

I'm still working on it :) Currently I'm working on better tests and
examples, but for now included test.cpp must suffice. Documentation so far
is only in the form of code comments, I'll take care of this later.

> From: Larry Evans
> > Just uploaded to http://www.boost-consulting.com/vault in the
> > Template Metaprogramming directory in range_all.zip.

I looked into the code, but I must say I'm far from being an mpl expert and
I had difficulties with understanding the code ;-) Maybe you could look into
my code and figure out if it could be reused?

As to the function-local static objects - I've created another bounds
specifier class which doesn't create any statics and made it the default,
the static version is still available though.

And another thing, which is quite important and many people may ask about
this - why bounded_int and the like doesn't take only MinValue and MaxValue
parameters and deduce the underlying type to be the smallest type that can
hold both the values? At first I also thought it's a very good idea, I even
implemented integral_bounds wrapper for autoamtic type selection. But then I
came to conclusion that automatic type selection can more harm than help.

Consider such situation: let's assume that unsigned char's range is <0, 255>
and you want to create bounded_int<0, 255>. What underlying type would be
used? That would be unsigned char. That's great, this is what we wanted - no
space is wasted, the automatic type selection has chosen the most
appropriate type. But this bounded type is useless for any operations other
than incrementing/decrementing! If we try to assign any out-of-bounds value,
it'll be truncated to unsigned char before assignment, and the assigned
temporary will of course lay within bounds - from the point of view of
bounded_int everything's OK.

To avoid the problem of overflows, we could select some type larger than
unsigned char, on which one can perform the wanted operations without
overflows. But how much larger? It depends on the operations one's going to
perform. But howcome the auto type selection mechanism is supposed to know
how much is "enough" for us? It can't, and therefore I think that type
selection should be a conscious decision of a programmer, not left to any
magical wizard. Making the automatic type selection mechanism select a type
at least twice as big as needed could be a solution. This way we can protect
ourselves against overflows in most situations. But unfortunately not all,
and so I'm also afraid that using such mechanism could be a bad idea because
a programmer who uses it, assuming it's safe in "most situations", could
forget about situations in which it's not and write code which does contain
overflows.

The best (and only, I think) way to avoid any overflows is to use some
unlimited range integer class as the underlying type (like
::std::N1744::integer or mentioned somewhere big_int). A little worse
solution, that doesn't allow to avoid overflows, but at least signals them
by throwing an exception, is to use a safe integer class (similar to
safe_int described at
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dncode/html
/secure01142004.asp). The problem with these solutions is that they both
aren't available in Standard C++ nor in Boost yet.

Best regards,
Robert