Boost logo

Boost :

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

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.


Boost list run by bdawes at, gregod at, cpdaniel at, john at