From: Jeffrey Faust (jefffaust_at_[hidden])
Date: 2007-06-21 23:17:51
On Thu, 21 Jun 2007 11:55:30 -0700, Robert Ramey <ramey_at_[hidden]> wrote:
> Sohail Somani wrote:
>> On Thu, 2007-21-06 at 17:56 +0000, Jared McIntyre wrote:
>>> I changed ARCHIVE_VERSION in basic_archive.cpp to 3 (from 4) and this
>>> for me. Luckily, I'm not using any collections whose serialization
>>> format has
>> Even if you are, shouldn't it be class_version that matters *not* the
>> serialization library version?
> a subtle but important distinction.
> versions numbers are generally attributes of the class
> Including version information with class serialzation can include a small
> performance penalty and I thought it reasonable for STL serialization
> to never change (silly me). So I left the STL serializations
> When it came time to change the STL serializations - I had to bump
> the "global" library version and use that number to branch code.
It might be worth sharing my experience with this change in version
number. Our product has its own saved files, which are themselves
versioned. The mechanism for doing this is as old as C++ and is very
intrusive. I came up with a mechanism to embed boost::serialization
output in our saved files. Very very slick. Good job, by the way.
When I upgraded to 1.34.0, some of our tests started to silently fail.
Surprisingly, there was no crash, and we attributed the differences to
something else entirely. It took a bit of effort to realize the values
were not restoring the same as before.
When we determined it was a serialization issue, I immediately looked in
the documentation for any notes about breaking changes. I searched the
mailing list for references. Nothing helped.
I then stepped through the code to determine what changed, which revealed
the item_version (if I remember correctly) change which was bracketed by a
boost archive version check.
The fix was fairly straight-forward. Since we have our own version
numbers, I merely created a mapping of our versions to boost archive
versions. I also added some code that will immediately crash the
application as soon as the boost version is incremented again so the
developer knows to update the mapping and bump our version number.
All's well that ends well, but some more information up front would have
helped me track this down faster.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk