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

From: Matthias Troyer (troyer_at_[hidden])
Date: 2008-06-12 15:29:35

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#differences_1_34 
> .

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