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