From: Dave Harris (brangdon_at_[hidden])
Date: 2002-11-17 19:15:34
On Sun, 17 Nov 2002 23:08:02 +0100 Matthias Troyer
> 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 acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk