[boost] [serialization] Boost 1.35.0 version breaks backward compatibility.

From: Jurko Gospodnetiæ (jurko.gospodnetic_at_[hidden])
Date: 2008-06-12 08:45:52

   Hi all.

   I am not sure if this was the desired or even acceptable effect but 
Boost 1.35.0 version of the serialization library introduces an 
optimization in vector.hpp when serializing a std::vector of 'trivially 
constructible' types (e.g. int :-)) that breaks backward compatibility 
when serializing into a text archive.

   Example for a std::vector<int> holding values { 2, 4 }:
     Old implementation: '2 0 2 4'
     New implementation: '2 2 4'

   We found a workaround to make boost use the old serialization 
implementation by wrapping our 'default constructible' objects inside a 
a simple class with a non trivial constructor.

   None of this is documented in 
http://www.boost.org/doc/libs/1_35_0/libs/serialization/doc/release.html#differences_1_34.

-----------------------
Some related questions:
-----------------------

   * Does anyone know if Boost serialization library is intended to 
remain backward compatible across different Boost releases or at least 
provide for explicitly turning on such backward compatibility?

   * What to do when one wants to use new & improved serialization 
algorithms but needs to occasionally support older ones in the same 
application? I know our class serialization can be conditioned based on 
some 'version' parameter but what to do about 'standard' classes, e.g. 
std::vector<int>, whose serialization is implemented by the Boost 
serialization library itself? For example, a new 'network application' 
release supports a new & improved serialization algorithm but still 
wants to support connecting to old 'network applications' that do not 
know how to 'speak the new language'.

   Many thanks for any explanation regarding this topic.

   On a related but separate issue - The optimization is conditioned on 
whether the type is 'default constructible' which seems incorrect. 
Default constructibility test as currently implemented does actually 
just test whether the constructor is trivial (using a compiler specific 
intrinsic) but that is not what the name 'has_default_constructor()' 
suggests.

   Hope this helps.

   Best regards,
     Jurko Gospodnetiæ