Re: [Boost-users] size_type doubts / integer library..

From: Andrea Denzler (andrea_at_[hidden])
Date: 2008-08-17 15:16:29

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_at_[hidden]
[mailto:boost-users-bounces_at_[hidden]] Per conto di Zeljko Vrba
Inviato: domenica 17 agosto 2008 20.31
A: boost-users_at_[hidden]
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_at_[hidden]
http://lists.boost.org/mailman/listinfo.cgi/boost-users