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 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 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?
I don't see the problem. On one platform int32_t is typedef'd to long and
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?
> As I mentioned in the introductory part of my post, text archives are
> much longer than binary ones and thus cause bandwidth problems for some
> applications.
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 posted an algorithm earlier. I think now it could be turned into a pair
of archive subclasses and used (by these subclasses) as their int format.
There would still be some cases where an int16_t would take up 3 bytes
rather than 2. If this is a problem I wonder whether you should use
write_binary() directly for those numbers, or rather, a wrapper that does
that. Such wrappers don't need to be members of basic_xarchive.
The main problem with this is that write_binary() may not produce very
readable output for text archives. (In my view it should produce a hex
dump.)
-- Dave Harris
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
