Subject: Re: [boost] [serialization] string serialization
From: Nikolay Mladenov (nikolay.mladenov_at_[hidden])
Date: 2009-03-04 13:56:02
On Wed, Mar 4, 2009 at 1:43 PM, troy d. straszheim <troy_at_[hidden]> wrote:
> 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?
correct, it is not possible.
> 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.
As far as I can tell this is already done by the binary_archives.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk