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

-----Messaggio originale----- Da: boost-users-bounces@lists.boost.org [mailto:boost-users- bounces@lists.boost.org] 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. 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 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 :)