Re: [boost] [serialization] string serialization

Subject: Re: [boost] [serialization] string serialization
From: troy d. straszheim (troy_at_[hidden])
Date: 2009-03-04 16:11:37

Nikolay Mladenov wrote:
> On Wed, Mar 4, 2009 at 1:43 PM, troy d. straszheim <troy_at_[hidden]> wrote:
>>
>> 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.

So it is.  This looks good to me:

namespace boost { namespace serialization {

BOOST_STRONG_TYPEDEF(std::size_t, collection_size_type)

} } // end namespace boost::serialization

But this looks bad:

void save_override(const serialization::collection_size_type & t, int){
// for backward compatibility, 64 bit integer or variable length integer 
would be preferred
    unsigned int x = t.t; //    :(
    * this->This() << x;
}

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

Yeah apparently so.  I see what you're getting at: for certain scenarios 
the binary archives are almost portable.  Again IMV that is only 
accidentally the case, shouldn't be that way, and one shouldn't depend 
on it.

Anyhow, attached is the portable binary i/o archive we've been using, 
for the scenario mentioned.  Hack out the bits that refer to very old 
boost versions (for which there is a different archive 
implementation)...   I think this saves things the way you want them. 
HTH...

-t