Boost logo

Boost :

From: Dave Harris (brangdon_at_[hidden])
Date: 2002-11-17 16:49:34

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 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

-- Dave Harris

Boost list run by bdawes at, gregod at, cpdaniel at, john at