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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk