
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)