Re: [Boost-users] [serialization] class versioning changes in boost 1.42 [patch]

David Raulo wrote:

On Sat, 27 Feb 2010 10:17:19 -0800 "Robert Ramey" wrote:

...

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.

which is good thinking. what I really want to do is to use uint_least_8_t to document and enforce the current design.

Out of curiosity, do you know of a c++ compiler on some boost-supported platform which is using 16 bits ints?

When faced with writing something like the serialization library one can take two approaches:

Some beefy microcontroller perhaps? Or is this concern about 16-bits ints purely hypothetical?

a) select the group of compilers that one is interested in and make sure everything works for all members of that group. b) code to the C++ standard. Then introduce work-arounds for those compilers which fail to support the standard in some way. I've chose b) because it results in much portable code and is less work to implement and maintain. In short, it's scalable. One only needs to consider differences between each compiler and the standard rather than an ever larger group of compilers. There are other reasons to support doing it this way but these are enough for me. One thing that is a bad idea, and this case illustrates it, is to make assumptions about the implementation which are not explicit. That is - if a integer has to be able to contain 32 bits for the program to work, one should use a type which indicates and guarentees that.

Try to see it that way: you seem to be implying that using uint_least32_t now would somehow increase risks of future problems,

Actually, it would create problems immediately. In fact, you have one right now. You haven't come upon it because you only use a type of archive where the problem doesn't show up.

but at the same time you suggest that we do just that.

Well, your case is special now.

Now I'm wondering what those risks really are, and if we should take them.

I suppose the risk is that there is another ambiguous issue inside the library that no one knows about which could later become a problem. You'll have to weigh the risk of alternatives- writing your own code, using a different library, etc.. to determine if they're less risky.

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.

Your situation is a concrete case. If you want to use binary_archive to to make the process faster, you can't. Your program will fail.

...

...

- Would this patch cause any regression? Break any user code which was working fine before? Break user archive backward compatibilty?

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.

Thinking about it some more, I'll look into the possibility of permiting the loading of larger version # from older text archives. I see now that's what you have in mind. I would likely implement it in a different way but I think I can make it work. I'll have to think about it.

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? ;-)

Not that it matters - but this is totally not understandable to me.

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?

Actually, it would be easy to "upgrade" the version # to 32 bits. But this would only encourage more mis-usage of the version # and make all binary_archives a little bit bigger. Give me some time to think about it some more. Robert Ramey