In-Reply-To: <0A393DE9-FA79-11D6-9B0B-0003939BD83A@[...].ch> 
On Sun, 17 Nov 2002 23:08:02 +0100 Matthias Troyer 
(troyer@itp.phys.ethz.ch) 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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost