On Thu, 25 Feb 2010 08:49:50 -0800
"Robert Ramey"
Vladimir Prus wrote:
Robert Ramey wrote:
Well, I assume that most folks who use Boost.Serialization don't post here to report what version scheme they have used. So, I suggest you don't make broad conclusions based on the number of reports.
I would expect that people running across problems with the scheme would post here. So I think it's correct that this hasn't been a problem up until now.
Maybe we are the only ones to use big version numbers, maybe not. In the later case these users will only get bit when they switch to boost 1.42. So it may be a little early to judge.
The signature for loading is:
void load(Archive & ar, T & t, const version){
Maybe it would be a good idea to change this signature to reflect the actual contract on version numbers, so new users can not miss it.
in addition, there is a serialization library version returned with get_library_version. This is used internally by the library to address changes in serialization of primitives and other types for which class information is not kept in the archive. I believe that this version # is now up to 4.
Did this number change with boost 1.42? If yes I could use it to detect these archives and work around my problem.
Their usage of the version number presumed a 32 bit integer. binary archives only use 16 bits. So their change would make it impossible for them to use binary archives.
Actually, we did encounter this problem with binary archive early on, and we found that binary archive stored the class version as 8 bits (not 16). I guess I should have posted about this then. But this was not a regression (AFAICT binary archives always behaved like this), and it made sense that in a binary format you may want to save every last byte. So we switched wo XML, and did not report about it here since we assumed to be safe. I understand now that you did not anticipate our usage. About binary archives, I just did a test, and with boost 1.42 we now get an exception: /opt/boost-1_42_0/include/boost/archive/basic_binary_oarchive.hpp:83: void boost::archive::basic_binary_oarchive<Archive>::save_override(const boost::archive:\ :version_type&, int) [with Archive = boost::archive::binary_oarchive]: Assertion `t.t <= boost::integer_traits<unsigned char>::const_max' failed. and this is while saving an object with version 300 to a binary archive (100 works as expected). With an xml archive, and a version number of 100000, no exception, and the version is truncated to 16 bits.
Assuming the use classes are not changed, why program built with 1.41 cannot read archive created by 1.42?
It can.
Not in my case. That's how I initially discovered the problem. The class version properties in XML archives generated by 1.42 were truncated to 16 bits, and so could not be read back (with either 1.41 or 1.42).
In this particular case, the situation is that a program built with 1.42 cannot read an archive created by 1.41
yes, and I understand that.
BTW there is still something I do not understand here.
Here is an archive generated with boost 1.42 :
<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<!DOCTYPE boost_serialization>