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

From: Matthias Troyer (troyer_at_[hidden])
Date: 2002-11-26 15:10:15

On Tuesday, November 26, 2002, at 08:32 PM, Michael Walter wrote:

> DG> Robert Ramey wrote:
>
>>> We should discuss whether to use short, int, long ... as the 
>>> primitive
>>> types or int8_t, int16_t, int32_t, int64_t. The latter makes it 
>>> easier
>>> to write portable archives, the former seems more natural. I can
>>> accept both choices but we should not mix the two as is done now.
>
> DG> For who would it be less natural to use int32_t, etc instead of 
> int,
> DG> etc? Not the end user of the archive, right? And I think the 
> writer of
> DG> the archive would be more concerned with portability. And even 
> he/she is
> DG> not, the burden is not that great, is it?
>
> DG> AFAICT the advantages of int32_t etc outweigh the disadvantages. 
> But
> DG> perhaps I'm missing something?
>
> DG> Regards,
> DG> Dirk Gerrits
>
> If you aim for portability, you can simply use int8_t, int16_t, etc.
> in your implementation - no need to use it in the archive interfaces
> as far as I get it. Sorry if I miss the point :)

If a library user wants his archives to be portable he has to use 
int8_t, int16_t, etc.. for all data integral types that he wants to 
portably serialize. Having those types in the interface might help 
making users aware of the fact that they should use those types if they 
want their serialized archives to be portable. However just emphasizing 
this at a prominent place in the documentation might be enough.

Matthias