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