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