Actually the compiler issue a warning if you convert something that will create an overflow (like unsigned int to signed int). When there is no overflow you will get no warning (like unsigned char to signed int). Avoid such warnings writing your own conversion code (see assert below). What else can the compiler do since the value to convert is unknown (unless you have a const). To get an assert on integer overflow at runtime you must write your own integer class, handling the conversion from all integral types (modern CPUs doesn't offer interrupts on integer overflow). You will have an overhead of course, but it can be minimized very well using assembler instructions. The operators < and > works well mathematically. The problem with -1U < 2 is that you are going to have an overflow because you are converting -1 to unsigned. This happens before the operator is applied (it require both value of the same type). -----Messaggio originale----- Da: boost-users-bounces@lists.boost.org [mailto:boost-users-bounces@lists.boost.org] Per conto di Michiel Helvensteijn Inviato: domenica 17 agosto 2008 19.13 A: boost-users@lists.boost.org Oggetto: Re: [Boost-users] size_type doubts / integer library.. Zeljko Vrba wrote:
Actually, I think I could simplify my requirements a bit:
I strongly agree with your proposal, and pretty much everything in your post. I would also like the possibility to explicitly state the lower- and upper-bound in the type and the possibility to use a dynamic integer (without any bounds), should the need arise. In my opinion, the ideal solution would be to have only one int type in the language, which would conceptually have no bounds. Convenient sub-types (like uint) would be defined which would enforce type-invariants (like: value >= 0). The programmer may also define his own sub-types. All int-types would be compatible, however, and behave correctly in a mathematical sense. If an operation between two integers overflows, an assertion failure would arise. This is clearly not possible for C++. But I'm designing a programming language where integers work this way. The hope is that the bounds of a plain int may be found (formally proved) at compile-time, so it can be cleanly mapped to a hardware-int without any runtime overhead. If the programmer specifies bounds, they are either proved correct at compile-time or enforced at run-time. In all other cases, a dynamic int is used. This should completely eliminate unexpected runtime overflow. I'm also thinking of making int itself a subtype of a bit-array, which would take care of bit-shift operations. But I'm not really sure how that would work yet for all integers, since I would like to make the behavior hardware independent and predictable. -- Michiel Helvensteijn _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users