Re: [Boost-users] Boost Serialization tracking issues 2

From: Robert Ramey (ramey_at_[hidden])
Date: 2007-08-15 11:56:06

Robert Ramey wrote:
> OK - I see the problem - good example. I don't see an obvious or
> easy fix.  I'll look into it.
>
Thinking about this some more.

> Sergey Skorniakov wrote:
>> Unfortunately, current tracking implementation can also leads to
>> weird version incompatibility. The unlucky combination is
>> object_serializable + track_selectivly. Suppose, someone have code
>> that serizalizes vector<int> to file (by value). After some time,
>> some code that serializes vector<int> as pointer is added to program.
>> Its enough to make old files unreadable (or readable with errors).

This issue was considered in the implemenation.  The fact that at type
is tracked/untracked is written to the archive when the data is saved.
Tracking at load time is determined by the corresponding flag in the
archive and NOT the current attribute.

Soooo this will have to be looked into.   standard library collections
are a little different in that they are unversioned.  I don't know if that
makes a difference, but we'll look into it.  Its also very odd the
behavior is different depending upon the type of archive.

Robert Ramey

>> Sample code:
>>
>> void TestTrack2Err(boost::archive::polymorphic_xml_iarchive &ar)
>> {
>>  std::vector<int> *p;
>>  ar & BOOST_SERIALIZATION_NVP(p);
>> // saving of vector<int>* is absent intentionaly to simulate
>> different versions of saving and loading code }
>> void TestTrack2()
>> {
>>  std::stringstream s;
>>  std::vector<int> x;
>>  x.push_back(4);
>>  {
>>    boost::archive::polymorphic_text_oarchive ar(s);
>>    ar & BOOST_SERIALIZATION_NVP(x);
>>  }
>>  x.clear();
>>  {
>>    boost::archive::polymorphic_text_iarchive ar(s);
>>    ar & BOOST_SERIALIZATION_NVP(x);
>>    assert(x.size() == 1);    // The vector is empty at this point -
>>  unless loading of vector<int>* is commented out }
>> }
>>
>> The consequences of error can vary from noting (especially with xml
>> archives) to program crashes in some more difficult cases. I have
>> recently encountered this error when dealing with a big project (more
>> than 500 serialized types) and have no idea how I can get out of a
>> difficulty.