Re: [boost] [constrained_types] Here it is :D

From: Dan McLeran (dan.mcleran_at_[hidden])
Date: 2005-10-06 22:23:59

Robert,

I just started playing with your latest post, I think it looks great.
"Robert Kawulak" <kawulak_at_[hidden]> wrote in message 
news:!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAAg4xUPOJl6UarljpIQw8sgsKAAAAQAAAAwtA
> 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
>
>
> _______________________________________________
> Unsubscribe & other changes: 
> http://lists.boost.org/mailman/listinfo.cgi/boost
>