Boost logo

Boost :

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

In-Reply-To: <0A393DE9-FA79-11D6-9B0B-0003939BD83A_at_[hidden]>
On Sun, 17 Nov 2002 23:08:02 +0100 Matthias Troyer
(troyer_at_[hidden]) 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?

Byte order is surely an additional issue. I'd expect arithmetic with
int32_t to use the byte order of the local CPU, else it would be horribly
slow. Using int32_t in the API won't automatically give a byte order

If you want an archive with a standardised byte order, can't that be done
within the current base class API? It ought to just need suitable derived
classes to be written. I don't think an architectural change is needed.

Any approach will surely involve some processing overhead, eg to do the
byte-swaps. Arguably applications which don't need a byte-neutral format
shouldn't pay for it. There ought to be the current dumb binary archive
format in addition to whatever sophisticated ones we need.

> > If you do need variable-length you could use a /binary/
> > variable-length format.
> I just need well-defined fixed length, and thus use int*_t instead if
> int, long or short in all my codes.

I suggested the binary variable length format because it copes with byte
order and int size issues naturally.

-- Dave Harris

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