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

From: Sergey Skorniakov (s.skorniakov_at_[hidden])
Date: 2007-08-15 05:51:33

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


"Robert Ramey" <ramey_at_[hidden]> wrote in message news:f9qnba$req$1_at_sea.gmane.org...
> LOL - well it IS surprising.
> 
> Take a look at the documentation for the class serialization trait 
> "Implementation Level".
> 
> This touches upon a really big issue with a library such as this.  Question 
> is
> which do you do:
> 
> a) always the right thing
> b) always the same thing - and maybe emit a warning or error when its not a 
> good idea
> 
> Choosing b) makes for a transparent system and this is what I usually 
> prefer.
> Generally I detest hidden features, attributes, which make things look 
> easier but in fact produce
> surprising side-effects.  When tthings fail it means a huge effort trying to 
> get
> to the bottom of things - often the only recourse is by trial and error.
> 
> a) is much more popular today.  It seems easier and makes a better demo.
> And its seductive - let's design it so "it just works".  If there is one 
> program
> in my whole life which has tested my sanity its Microsoft Word.  (next in
> line might be bjam).
> 
> In practice I usually prefer b) but sometimes - like this one - I give 
> myself a
> pass and slip into a).  In this case it was deliberate design decision to 
> "do
> what the user probably wants if he doesn't otherwise specify it".  In spite
> of my prejudice generally against this kind of thing, I think in this case 
> it
> has worked to advantage as I have gotten very few complaints and
> problems about it.
> 
> There might be a few other places where something similar has been done - 
> but these
> would also be exeptional cases.
> 
> So I sympathize with your point of view in general, I just don't think
> its the correct one in this particular case.
> 
> Of course, if one is going to do something like run 1 TB through the
> serializer, he really should carefully read the manual, and carefully
> consider what he's doing.  I wouldn't trust me to have done the right thing 
> .
> 
> Robert Ramey
> 
> gast128 wrote:
> 
>> Thx for the answer. My point is that if you nowhere specify a
>> load/store through pointer, the following code stores just multiple
>> copies:
>>
>> for (int i = 0; i < 100; ++i)
>> {
>>   const SomeStruct s;
>>   oa << s;
>> }
>>
>> but this behavior seems to change if somewhere a store through is
>> performed. This was for my surprising.