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

From: Andrea Denzler (andrea_at_[hidden])
Date: 2008-08-18 12:45:49

> -----Messaggio originale-----
> Da: boost-users-bounces_at_[hidden] [mailto:boost-users-
> bounces_at_[hidden]] Per conto di Lang Stefan

 
> 3. Integral types situation
> B) What makes this problem even more difficult, is the widespread use of
> libraries, which may or may not use signed/unsigned values for specific
> properties, and thus don't even leave it open to the developers to avoid
> such combinations!

This is the worst part.... using a library and handling all that
conversions.

> C) Built-in integral types are based on internal representations of
> numbers. From the perspective of a designer this is just plain wrong! It
> is a violation of the principle of information hiding! 

I completely agree with you. The idea behind fixed integer types is to limit
memory usage to the real needed value. Else let's go all with 64bit signed
integers even for a boolean. 

The old way to define this is specifying the byte size, but a better
approach should be something like integer<min,max>. Where min max are signed
and or unsigned constants. I don't care how may bytes  the compiler will
use, I care as less as possible bytes/bits. 

And since I want crossplatform code this new type must support a totally
portable serialization function. And of course also other standard functions
like sprintf.

And since I want a good debug code it should support options for assert and
exceptions when any kind of overflow is detected, through assignments from
other similar types, through arithmetic operations, and so on. Even a
compiler warning is welcome when I do an assignments that lead potentially
to an overflow.

> D) (Of course this implies the annihilation of current integral types
which won't happen for some time, even after a standard basic adaptable
integral type would be provided.)

Let's say that all existing integral can be aliases of a specified
integer<min,max> type. And this alias depend on the platform. So we can
introduce easily the new integer features on all existing libraries.
 
> So these are my 5 cents, sorry for the lengthy post.

Thanks for your very nice post :)