Re: [boost] [serialization] New version number in 1.34

From: Robert Ramey (ramey_at_[hidden])
Date: 2007-06-21 14:55:30

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
>> worked
>> for me. Luckily, I'm not using any collections whose serialization
>> format has
>> changed.
>
> 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 
definition/declaration.

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

When it came time to change the STL serializations - I had to bump
the "global" library version and use that number to branch code.

The funny thing about this is that I branched the "save" code as well
as the "load" code.  (except in optional.hpp).  I know I did this without
thinking about it, I just implemented symetry out of habit.

SO I see now that with relatively small effort - adding a function to the
output archive interfac - set_library_version(int) - one could generate
backward compatible archives.  Except for one thing - the classes which
store thier versions along with the class.  In order to implement this one
would do the following:

a) implement "version awareness" for the classes "save" functions.  I
would guess the difficulty of this would depend upon the features
of the already implemented serialization.

b) replace the BOOST_CLASS_VERSION(<class name>, <latest class version>)
with BOOST_CLASS_VERSION(<class name>, <older class version>). I
presume that those who do this would make them selves some pre-processor
code which invokes the correct version macro.

I suspect this might not be doable with some of more complex serializatons
such as shared_ptr - but anyway.

All this actually turns out to be kind of amazing to me and totally 
unexpected.

If someone thinks this is interesting and/or important enough to make 
demo/test
along with an addition to the documentation (see - case studies), I would
be willing to make the minor changes in the code to support this.

Robert Ramey

> Sohail
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost