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@mac.com> wrote in message news:cl5tad$ghm$1@sea.gmane.org...
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?
yes
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"
Thanks
Russell
_______________________________________________ Unsubscribe & other changes: