On Sunday, November 17, 2002, at 10:49 PM, Dave Harris wrote:
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?In-Reply-To: <[EMAIL PROTECTED]> On Sun, 17 Nov 2002 10:19:23 +0100 Matthias Troyer ([EMAIL PROTECTED]) wrote:It can cause troubles, since for my portable codes I use int64_t orI don't see the problem. On one platform int32_t is typedef'd to long and
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 32-bit.
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?
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?
I just need well-defined fixed length, and thus use int*_t instead if int, long or short in all my codes.As I mentioned in the introductory part of my post, text archives areIf you do need variable-length you could use a /binary/ variable-length
much longer than binary ones and thus cause bandwidth problems for some
applications.
format. This wouldn't have the verbosity of text. Indeed, for many uses it
would be shorter than your preferred fixed-length format.
Matthias
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
