I may add that C/C++ have different integer sizes on different platforms adding even more confusion. I understand that a basic int has the size of the processor register, but when I handle and store data values I want to know it's size. When I want a 16 bit integer then I want to use a 16 bit integer because I don't waste space with a 32 bit or have data structures of different sizes. Even worse the size of the wchar_t for i18n. A signed/unsigned compare should always generate a warning, but I just found out it doesn't if you use constant values like -1 < 2U. Funny. signed int a=-1; unsigned int b=2U; bool result = a < b; // as usual I get the signed/unsigned warning Technically if you compare/add/sub two signed/unsigned values of the same byte size then you are having an overflow because signed values doesn't exist in the unsigned realm and you have a double amount of unsigned values. That's why a class (or new standard integer types) handling those confusions is really welcome. Until now I rely on crossplatform integer sizes (uint16, uint32, uint64, etc) and compiler warnings. I think compiler warnings are important because you always know there is something to care about. An overflow assert at runtime can happen or not happen. So ideally we should handle at compile time explicitly all incompatible integral types (signed/unsigned of same size) and have at runtime (at least in debug mode) asserts for any kind of integer overflow (through casting from signed to/from unsigned and basic operations like add, sub, mul, div, etc). imho.... -----Messaggio originale----- Da: boost-users-bounces@lists.boost.org [mailto:boost-users-bounces@lists.boost.org] Per conto di Zeljko Vrba Inviato: domenica 17 agosto 2008 20.31 A: boost-users@lists.boost.org Oggetto: Re: [Boost-users] size_type doubts / integer library.. On Sun, Aug 17, 2008 at 07:43:14PM +0200, Andrea Denzler wrote:
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.
That's what I proposed. I listed my requirements and asked whether such a library already existed :-)
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).
Well, the first expression was a typo, it should be -1 < 2U. Technically, no overflow happens because signed->unsigned conversion is well-defined (even for negative numbers). I know _why_ it happens, I was complaining on the definition which mathematically makes no sense. == It is ironic that the experts recommend to use signed integers, yet the language definition is backwards since it is biased towards unsigned arithmetic: in three of four possible mixes (s/u,u/s,u/u) the arithmetic is unsigned, and only in the s/s case the arithmetic is signed and behaves according to the usual mathematical definitions. Given the language as it is, the advice should be to use unsigned most of the time, because it is contagious and has always a defined behavior. So one should actually only cast to a signed type only at the moment a signed interpretation is needed. This works nice for 2nd complement which preserves signedness even with unsigned operations (at least across add/sub), though it would probably horribly break with 1st complement or sign-magnitude representation. Blindly multiplying or dividing and reinterpreting the result as signed will break (i.e. give incorrect result) even with 2nd complement representation. <rant>~30 years since C has been invented, ~20 since C++ has been invented, and they still have no sane integer arithmetic defined, not even as an option *shrug*</rant> <sarcasm>I guess the best choice is to use float, at least one knows what to expect.</sarcasm> _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users