Re: [boost] int vs int32_t [was: Serialiization Review repost with consistent quoting]

From: Matthias Troyer (troyer_at_[hidden])
Date: 2002-11-27 12:53:27

On Wednesday, November 27, 2002, at 06:05 PM, Kevin Lynch wrote:

> Michael Walter wrote:
>
>>> If a library user wants his archives to be portable he has to use
>>> int8_t, int16_t, etc..
>
> I don't remember seeing this pointed out, so forgive me if I just 
> missed it or am just stating the obvious, but:
>
> These types are technically NOT portable, in two ways:
>
> 1) They are not defined by ISO C++ ... although they are required by 
> POSIX 1g, and are optional types in ISO C, C++ compilers are not 
> required to support them.

We seem to support them in boost, thus that's no problem.

>
> 2) Although both POSIX and C99 define them to be 2's complement 
> integers with the appropriate number of bits, neither standard sets a 
> requirement on byte ordering within the multibyte types.  Thus, even 
> if a platform supports them (say, the BSD family), the binary form of 
> the integers is not portable.
>
> So, while use of them may lead to a MORE portable C++ interface, they 
> won't directly lead to a portable binary serialization format 
> (although you can clearly fix that problem in platform specific byte 
> reordering code).

Agreed. It would just make the task of implementing a portable binary 
serialization easier, since we know the width of the types. However, we 
can also do the internal (private) implementation based on these types 
and dispatch from operator<<(int) to the appropriate function for 
serializing an integer with sizeof(int) bytes.

In any case the library user should be reminded that short, int and 
long are never portable, but that by using int*_t and appropriate 
archive formats one can achieve portable serialization.

Matthias