From: Matthias Troyer (troyer_at_[hidden])
Date: 2002-11-17 17:08:02
On Sunday, November 17, 2002, at 10:49 PM, Dave Harris wrote:
> In-Reply-To: <A94F12D0-FA0D-11D6-93CD-0003939BD83A_at_[hidden]>
> On Sun, 17 Nov 2002 10:19:23 +0100 Matthias Troyer
> (troyer_at_[hidden]) wrote:
>> It can cause troubles, since for my portable codes I use int64_t or
>> int32_t to be portable. In order for the library to write numbers in
>> binary consistently we should also serialize them as 64-bit ore
>> How do you do that when the bit size can vary from platform to
>> platform? Do you check at runtime what the number of bits is and
>> dispatch to serialization for that number of bits?
> I don't see the problem. On one platform int32_t is typedef'd to long
> the binary code boils down to:
> read_binary( &_Val, sizeof(long) );
> On the other int32_t is typedef'd to short and the code boils down to:
> read_binary( &_Val, sizeof(short) );
> But since sizeof(long) on the first platform is sizeof(short) on the
> second platform, the code is compatible. As long as the typedef's are
> right, how can the serialisation go wrong?
It will not go wrong, but the implementation has to check for
sizeof(short), etc., before deciding on how to serialize the short (we
might want to change byte order, ....) . On the other hand, if the type
is int16_t or int32_t I can just serialize that. I agree however that
one can work around that restriction. But, since int64_t is used
anyways, why not also use the other int*_t types?
>> As I mentioned in the introductory part of my post, text archives are
>> much longer than binary ones and thus cause bandwidth problems for
> If you do need variable-length you could use a /binary/ variable-length
> format. This wouldn't have the verbosity of text. Indeed, for many
> uses it
> would be shorter than your preferred fixed-length format.
I just need well-defined fixed length, and thus use int*_t instead if
int, long or short in all my codes.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk