Boost logo

Boost :

Subject: Re: [boost] [serialization] string serialization
From: troy d. straszheim (troy_at_[hidden])
Date: 2009-03-04 08:24:42

Robert Ramey wrote:
> Nope, It's not intentional.
> I don't remember why it is the way it is. Collections evolved
> to become more efficient and in the process collection_size_type
> came into being. Since std::string was already primitive and had
> a special implemention there hasn't been any motivation to mess
> with it. I'm not even that enthusiastic about colllection_size_type.
> Turns out that each std collection has its own size_type. So this
> makes thing even more confusing.
> It's the way it is because there was no obvious better choice.

I think it is a reasonable choice. The more control serialization gives
me over how things are stored, the less likely it is that a change in
the serialization library will make it impossible for me to maintain an
archive that is binary compatible with previous versions of
serialization. (In our case, the previous version is v1.33.1, and in
this case one needs special handling for strings anyhow.) For other
containers, the fact that serialization maps the varying size_types of
std collections to one type simplifies things. If I don't like it, I
can supply my own serialization routine for the container in question.
In the general case (as has already been discussed ad nauseam), I'd
argue that 'portable' has a context-dependent meaning (e.g. are ieee754
floats 'portable' for this use case? Is little/big endianness
required?) and it is up to the user to build an archive that implements
whatever 'portable' is to them.

Regarding the complaint about strings. For our (perhaps narrow)
definition of portable:

* 32/64 bit intel platforms, linux and osx, which implies little-endian

* floats stored on disk in ieee754 format

* serializable types required to use stdint typedefs where types vary
across the platforms we run on (for us this basically means 'no plain
longs', but when/if 128 bit platforms come around, we may need to go
back and change our 'ints' to int32_t)

* binary compatible with archives from a venerable custom binary archive
built on top of 1.33.1.

We can get away with just the following in our
template<class Archive, class Elem, class Tr>
class portable_binary_iarchive_impl :
   public basic_binary_iprimitive<Archive, Elem, Tr>,
   public basic_binary_iarchive<Archive>

// ...

void load_override(std::string& s, BOOST_PFTO int)
   uint32_t l;
   this->load_binary(&(s[0]), l);

void load_override(class_name_type& t, BOOST_PFTO int)
   std::string cn;
   this->load_override(cn, 0);
   if(cn.size() > (BOOST_SERIALIZATION_MAX_KEY_SIZE - 1))
   std::memcpy(t,, cn.size());
   // borland tweak
   t.t[cn.size()] = '\0';

void load_override(boost::serialization::collection_size_type& t,
                    BOOST_PFTO int)
   uint32_t l;
   t = l;


Boost list run by bdawes at, gregod at, cpdaniel at, john at