Re: [boost] Re: Reminder: Serialization Library Review

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

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