From: Robert Ramey (ramey_at_[hidden])
Date: 2004-10-20 11:33:17
Actually there are two version concepts in the serialization library.
The first is the serialization library format version. This is the "3" in
the boost_serialization tag. Its purpose is to permit future changes in the
serialization library to be made in such a way that the future code can
detect and properly read archives created with previous versions of the
library. Hopefully this will rarely if ever change and almost never bee
needed by users of the library.
The second is the class version. This is designed to be used by library
users to permit them to change class definitions and still guarentee that
previously written archives are readable.
"Russell Hind" <rh_gmane_at_[hidden]> wrote in message
> The header of our xml archive looks like this:
> <?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
> <!DOCTYPE boost_serialization>
> <boost_serialization signature="serialization::archive" version="3">
> <CoatingScanConfig class_id="0" tracking_level="0">
> The object written as CoatingScanConfig didn't have a class version
> specified (and therefore there isn't one in the header).
> When writting this class, the version parameter is passed in to the
> serialize() method is 0 for the class, but when reading it, the version
> number is subsequently passed in as 3 (which looks like the archive
> version). Should it not be 0 also?
It certainly should - send me a code snippet. The package includes tests of
> Is 0 a valid version number for a class?
> If I specify the class version
> as 1, then reading and writing both get '1' as the version, but if I
> don't specify a version, or I specify 0, then writing gets 0, but
> reading gets '3'.
I would think that is a bug. I would like to see more information
> If 0 isn't valid, then could there be a static_assert catching this?
> And a quick usage question: If a class isn't versioned, is an inherent
> 'version 0' written to the archive so that a version number of 1 can be
> applied to the object later when it is modified, or do objects need to
> be given a version number from the start?
serialization traits determine whether or not a class is versioned. Default
is for non primititve types to be versioned and the default version number
is 0. The usage of version number when not necessary could be a performance
issue so there is the option of setting serialization traits for any type so
that versioning isn't done. For example, this is not done for STL
collections. Review the section of the documentation "serialization traits"
> Unsubscribe & other changes:
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk