The version # has always been 16 bits. The binary archive has always stored 16 bits for the version #. The code used an int - whose size varies between 16 to 64 bits depending on the platform. Text archives convert the int to a string and this conversion doesn't trap when the number passes 16 bits.
I see.
To deal with this, you really need to know which version of Boost was used to create the archive.
There is a mechanism for addressing these kinds of issues - it's the library version # as described in the documentation. So far, that # is up to 4.
Thanks, that's what I was after.
Do you realize that e.g. Microsoft Word 2007 can be instructed to save files in such a way that they can be loaded with Word 2003? What is logically impossible about that?
Can Microsoft 2003 word load files created with Microsoft word 2007? That is what we're talking about here.
Of course it can. Try it yourself (Word 2007 -> File -> Save As -> select the relevant file type). This capability is fundamentally important for many applications, and there's nothing magic or logically impossible about it. Networked applications need this capability as well. E.g. a newly developed client needs to be able to communicate with any number of older, deployed, servers.
Hmmm - I might be willing to say a) that the intention is to make such a guarentee b) and every effort has been made to that end c) and that every attempt has been made to anticipate the usage of the library d) and that the library has been in usage for many years e) and that versioning is a widely used facility f) that has had very few problems from users g) and that continual efforts are being made to make that guarentee stronger h) but that it's possible that there is something I haven't anticipated which will create a problem.
I'm confused. You indicate here that backwards compatibility is an *intention*, and yet the Boost.Serialization documentation indicates that backwards compatibility is a *guarantee* (Contents -> To Do -> Back Versioning -> "... Currently, the library permits one make programs that are guarenteed the ability to load archives with classes of a previous version..."). For end users of Boost.Serialization there is a big difference between a guarantee and an intention. * If backwards compatibility is a guarantee, then the breakage David came across is a regression, and would need to be fixed in a future version of Boost. * If backwards compatibility is a (best-effort) intention, then you can indeed take a pass on this breakage, and leave David to deal with it himself. But of course then the documentation should state clearly that backwards compatibility is an intention, not a guarantee. So which one is it? Regards, Jarl.