On Sat, 27 Feb 2010 10:17:19 -0800
"Robert Ramey"
David Raulo wrote:
- boost_version used to be an unsigned int, which for the vast majority of your users was 32 bits at least;
I believe that the C++ standard permits an int to be 16 bits. That in itself would be an indicator that assuming 32 bits might be an issue.
which is why I proposed using uint_least32_t, instead of going back to unsigned int. Out of curiosity, do you know of a c++ compiler on some boost-supported platform which is using 16 bits ints? Some beefy microcontroller perhaps? Or is this concern about 16-bits ints purely hypothetical?
See below a patch against svn. Can we please discuss its advantages and drawbacks? - what good does it do: obviously in my case, restore backward compatibility.
Why can't you just patch your own copy?
I might do that, or something completely different, depending on what I learn here. As I said earlier, maintaining our own variant of boost is inconvenient to say the least. We may as well completely abandon the idea of reloading old archives, and restrict our usage of serialisation for same-dll, same-boost cases. For long-lived models and guarantees of backward compatibility, I'm starting to believe we should do something else entirely. Try to see it that way: you seem to be implying that using uint_least32_t now would somehow increase risks of future problems, but at the same time you suggest that we do just that. Now I'm wondering what those risks really are, and if we should take them. There is a second risk factor that I must evaluate before starting to maintain a fork, which looks a lot more real to me: if the backward compat is broken again in the future, will we be able to work around it and continue to synchronize with official boost? Or would all that have been in vain? This is boost-level c++ we are talking about here, so I can definitely envision us not having the resources to do that in the long term. But for the sake of the argument, let's continue evaluating the downsides of that patch, which prevent it from being applied to official boost. Yes, I understood long ago that you won't, but with all that time spent arguing, you have not yet shown a single concrete scenario where applying that patch would create you or any user any problem. See below.
- Would this patch cause any regression? Break any user code which was working fine before? Break user archive backward compatibilty?
Would this not break compatibility with binary_?archive ?
No, it would not. Binary would continue to save only 8 bits, AFAICT.
Currently binary archive stores the version as a 16 bit integer. Maybe it wouldn't but it's another thing that would have to be considered. Even if it didn't, this would break the "guarentee" that any serialization which works for one archive class is guarenteed to work with any other one.
It does not do that either, because boost 1.42 actually restricts text archives to 16 bits and binary ones to 8. I do understand that it is an oversight, and that 1.43 will put everyone on 8-bits, equal footing :) The fact remains that this "guarantee" was never there before, is still not there, and so the patch does not incur any regression here either.
I thought you already ran into this when you tried to use a binary_archive.
Yes, and that was no regression, so not a problem, as I said. And everyone expect such limits on binary archives, because of their very nature. XML, not so much. Besides, binary and xml are not equal anyway wrt serialization. Imagine that scenario: a user becomes accustomed to the fact that xml archives, the only kind she tests at first, is portable between platforms. Her application becomes dependant on that portability. Then at one point she discovers that binary archives, which she wanted to use, are not portable. She is now stuck with XML. Strangely, you are not suggesting that we make xml non-portable, so that users do not "couple the concepts or archive and serialization", are you? ;-) And finally: if I were to complete the patch with code to enable 32 bits versions for binary archives too, that would take care of your only argument against the first patch so far, yes? Would you accept it then? Or is there another rule that I missed? -- david