In-Reply-To: <[EMAIL PROTECTED]> On Sun, 17 Nov 2002 23:08:02 +0100 Matthias Troyer ([EMAIL PROTECTED]) 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
