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

Subject: Re: [Boost-users] [serialization] class versioning changes in boost 1.42 [patch]
From: David Raulo (david.raulo_at_[hidden])
Date: 2010-02-27 17:00:15

On Sat, 27 Feb 2010 10:17:19 -0800
"Robert Ramey" <ramey_at_[hidden]> 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.  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