Subject: Re: [boost] [serialization] string serialization
From: troy d. straszheim (troy_at_[hidden])
Date: 2009-03-04 13:43:01
Nikolay Mladenov wrote:
> Considering your portability context (mine is even narrower):
> 1. the binary_archives already serialize
> boost::serialization::collection_size_type as unsigned int(uint32_t
> would still be better).
> 2.All this code will be unnecessary if the string serialization is not
> using "plain longs".
Okay... I understand the complaint about the size of strings not being
handled like the size of everything else, and agree that it would be
nice to be consistent. Because, well, consistency is nice. I was also
thrown by the special handling for std::string and had to spend some
time in the debugger, serializing things to disk and going through the
archives with hexdump. :/ C'est la vie.
But since the binary_archives don't make any claim about portability, it
would seem that you should serialize all sizes as std::size_t (often
'plain long'), even if the std library's containers' size_types aren't
consistent (which I wasn't aware of until Robert pointed it out. still
haven't checked.). I'd have to have a look: with a plain
binary_archive, is it not possible to save a std::vector with greater
than std::numeric_limits<uint32_t>::max() elements on a platform where
std::vector<T>::size_type is uint64_t?
If you buy that, then you still need to construct a
portable_binary_archive and handle container_size_type consistently
across architectures (e.g. convert to uint64_t before/after
storing/loading, checking for overflow on platforms where the in-memory
container_size_type is smaller than the on-disk container_size_type).
Then the difference is only that one currently requires an extra
override for std::string.
Boost list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk