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

From: dizzy (dizzy_at_[hidden])
Date: 2008-08-18 05:34:42

On Sunday 17 August 2008 22:16:29 Andrea Denzler wrote:
> I may add that C/C++ have different integer sizes on different platforms
> adding even more confusion.

How do you suggest that C++ offer integer types that are native to the 
platform then?

> 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.

So you have sizeof().

> 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.

I don't think bits matter in storage much. Because there is no system 
interface I am aware of that works with bits (POSIX file I/O, sockets I/O, etc 
all work with bytes). They all work with bytes, with the native platform byte. 
And sizeof() tells you the size in bytes. So you got all you need there to 
know how much space it takes to store that type.

> Even worse the size of the wchar_t for i18n.

sizeof(wchar_t) works as well.

> 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.

Not necessarily true (that unsigned have the corresponding signed type sign 
bit for value). There can be unsigned types for which the range of values is 
the same as the signed type (except of course the negative values).

> That's why a class (or new standard integer types) handling those
> confusions is really welcome. 

For what, for the issues Zeljko described or for the fixed integer size you 
said? For the former it's technically impossible to have native fast integer 
types and checked without runtime cost. For the later of course you can have 
as you can even make classes for fixed integer types (I have something like 
this in my serialization framework and the code takes fast code paths if it 
detects at compile time that the current platform matches well the fixed 
integer sizes that the user asked for).

> 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.

Of course, there is no doubt compile time checks are better than runtime ones 
(the main reason I like to use C++ and not C, since I have more compile time 
semantics to express more invariants at compile time using familiar syntax).

> 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).

I think his library idea does exactly this. Still, that doesn't mean the C++ 
native integrals are flawed :)

-- 
Dizzy
			"Linux is obsolete" -- AST