向量（反）序列化与Boost.serialization的向后兼容性

Question

Sorry for cross posting. After posting to the mailing list boost-users and one week without any responses I am inclined to post the issue at stackoverflow. Original Post, slightly re-edited:

Hi list,

I am migrating from Boost v1.35 to a new version. I have, however, some legacy serialized strings that I want to be readable by the new version.

After some testing I found that apparently the newer version (in this case 1.40 but also later) cannot correctly deserialize std::vector instances from 1.35 generated strings. Can anyone give my a pointer as to what may be the problem here?

Thanks a lot!

Ewald

==Details==

I use text archives, and gcc version 4.4.1 (Ubuntu 4.4.1-4ubuntu9)

The test vector is a structure with 2 items, the long integers 1 and 2.

Archive string for respective lib versions:

1.35: archive: 22 serialization::archive 4 2 1 2
1.40: archive: 22 serialization::archive 5 2 0 1 2

Now:

// includes
#include <boost/serialization/vector.hpp>
#include <boost/archive/text_iarchive.hpp>
#include <boost/archive/text_oarchive.hpp>

std::vector<long> testvector;
std::string val = "22 serialization::archive 4 2 1 2"; // v1.35 archive
{
std::stringstream ss(std::stringstream::in | std::stringstream::out);
ss << val << std::endl;
boost::archive::text_iarchive ia(ss);
ia >> BOOST_SERIALIZATION_NVP(testvector);
}

Result when executing with lib v1.40: testvector contains two elements, {2, 2} -- instead of {1, 2}

Note: s11n and de-s11n with the same lib version works perfect.

Answer 1

There is a file boost/serialization/vector_135.hpp at least in Boost 1.48 with this comment:

vector_135.hpp: serialization for stl vector templates for compatibility with release 1.35, which had a bug

I presume you could include it instead of boost/serialization/vector.hpp . The downside, of course, is that newly serialized vectors will be in that buggy format too in that case.

EDIT:

Brief study of the code suggests if the file is used, load() will be able to deserialize both formats, but save() will serialize in the new format. So, the only downside seems to be ugly include name then.