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: Robert Ramey (ramey_at_[hidden])
Date: 2010-02-27 13:17:19

David Raulo wrote:

> This is becoming ridiculous. Can we please get back to the
> actual issue?  Here are the facts :
>
> - 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.

> - boost 1.42 changed that to 16 bits;
> - in your mind it was always 8 bits and you were just trying to
>  enforce this in a more explicit way;

This is true.  Basically, I saw it as an oversight that it had not
trapped the usage of a larger integer and I was trying rectify
that.  Had I had the foresight to do this 9 years ago, this
problem would not have come up.  Now it can't come up
in the future.

> - this is not mentionned anywhere in the documentation or in the API.
> - you have at least one user who lost backward archive compatibility
>  because of this.

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

> - it gives more flexibility to the versioning scheme.  Two usefull
>  such schemes were described previously in the discussion, where
>  classes still have increasing integer versions, but are not possible
>  with 8 bits storage.
>
> - what downsides does appying this patch have?  Maybe occuring a
>  slight overhead on 16-bits platforms?  If true, can this be actually
>  measured?
> - 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 ?  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.

I thought you already ran into this when you tried to use a binary_archive.

Robert Ramey

> Index: boost/archive/basic_archive.hpp
> ===================================================================
> --- boost/archive/basic_archive.hpp     (revision 59943)
> +++ boost/archive/basic_archive.hpp     (working copy)
> @@ -37,7 +37,7 @@
> } /* boost */                                     \
> /**/
>
> -BOOST_ARCHIVE_STRONG_TYPEDEF(uint_least16_t, version_type)
> +BOOST_ARCHIVE_STRONG_TYPEDEF(uint_least32_t, version_type)
> BOOST_ARCHIVE_STRONG_TYPEDEF(int_least16_t, class_id_type)
> BOOST_ARCHIVE_STRONG_TYPEDEF(int_least16_t, class_id_optional_type)
> BOOST_ARCHIVE_STRONG_TYPEDEF(int_least16_t, class_id_reference_type)