Jarl Lindrud wrote:
Robert Ramey
writes: Jarl Lindrud wrote:
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.
Please reread my sentence above.
Let me try to make this more clear to you.
* Word 2007 can save files in a format that will *not* be readable by Word 2003. * Word 2007 can *also* save files in a format that *will* be readable by Word 2003.
LOL - Microsoft 2003 cannot load files created by Microsoft word 2007 unless they are specifically saved with that compatibility in mind. The ability to create a file compatible with some previous version is not supported by the library. The question has come up, and a cursory examination showed that it wouldn't be too hard to do. This is mentioned at the end of the documentation as ideas for future projects. But no one has had enough interest to work on this.
With Boost.Serialization I *cannot* make a program that produces archives that are guaranteed readable by programs that I've already built and deployed, because those earlier programs may well use an earlier version of Boost.
You can if you've used a class verision number which is less than 8 bits. Have you saved files with version # greater than 255?
And as you yourself acknowledged, in regard to point 2 in my very first post, archives created with newer Boost versions are not guaranteed to be readable by older Boost versions.
This is of course not true. One thing is Boost version. Class versions are an entirely different thing which has absolutely nothing to do with class version. I know I've said it before, but I can't believe you actually understand the issues here.
In fact, you stated that you don't even see any utility in such a capability, and then later that it is somehow logically impossible.
I'm talking about class versions here.
Can you at least see that there are serious real world applications (Word, for starters) that have this capability as a fundamental requirement?
Word can't do this. No program can. Microsoft word 2003 cannot read a file saved in Microsoft word 2007 format.
Boost.Serialization currently does not support this kind of versioning. Fair enough. But let's not pretend that it's some academic feature that no-one is interested in.
LOL
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.
It can and it does.
This capability is and has always been part of the serialization library. It it included in the documentation, demos and tests. Please read the documentation.
If the previously deployed servers use Boost 1.35.0, say, and my new client uses Boost 1.42.0, how can you claim that the new client will be able to send valid messages to the older servers? The Boost.Serialization documentation explicitly states that such compatibility is *not* supported (To Do -> Back Versioning). You even said so in earlier posts.
LOL
What am I missing?
You're totally lost here. I think I see it now. And this has in fact come up before. You've somehow got the idea that class versioning is somehow related to boost version #. The boost version # refers to the version of the serialization library code. The class version refers to the version of the class in one's own program. These are totally unrelated concepts whose only commonality is the word "version". The current boost serialization library can read archives created 10 years ago. The only requirement is that if the users code has added members, then the loading of those members has to be conditional on a class version number. The library assumes that this class version number is small integer.
It's only a guarentee if one follows the rules. In fact he did get
So there are unknown rules one should follow... Are there more unknown rules? Is the end user responsible for knowing about these unknown rules?
I'd have to go back and check the documentation to see what it says about version numbers. The examples all show small version numbers and the function signature uses "int" which the C++ standard permits to be at least as small as 16 bits. Also the binary_archive breaks if one tries to use a 32 bit integer. So it never occurred to me that someone might try to store a 32 bit number for the class version. In the latest iteration, we decided to compile boost at the highest warning level. Eliminating warnings resulted in including code to trap the storage of version # that are too big. So in the future these rules are better enforced.
lol - I write 30,000 lines of code with the intention of making no errors. I cannot guarentee that I have made no errors.
Car makers know that their cars are not perfect. When they offer you a guarantee, it doesn't mean "the car will never break down". It means, "if the car breaks down, we will fix it.".
There is a very simple fix - one line of code that can fix this users code. He can include it in his own version of the library and will have no problems loading his older files. This fix basically backs out the recent change and would prevent detection problems of this nature in the future. That's why I don't want to do it.
If Boost.Serialization's guarantee of backwards compatibility only applies under "anticipated usage" (as defined by yourself), then I guess that should be documented, along with your definition of "anticipated usage".
I'll add language to the documentation so that it's clear one should not use a number larger than 255 as a class version number. And I'll enhance the code to trap on violations of this rule in the future. Robert Ramey