[serialization] Boost 1.35.0 version breaks backward compatibility.
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#dif.... ----------------------- 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ć
On Jun 12, 2008, at 2:45 PM, Jurko Gospodnetić wrote:
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#dif... .
This is a bug that will be fixed in the next release.
----------------------- 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?
Yes, that's the intent.
* 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'.
There is also an archive version, for the serialization library version itself.
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.
This is a sufficient but not a necessary condition. Further optimization can be obtained by specializing has_default_constructor for your type. The next version will implement this slightly differently, and get rid of that trait. Matthias
participants (2)
-
Jurko Gospodnetić -
Matthias Troyer