On Sat, Dec 23, 2017 at 4:54 PM, Steven Watanabe via Boost < boost@lists.boost.org> wrote:
AMDG
On 12/23/2017 02:25 PM, Robert Ramey via Boost wrote:
On 12/23/17 10:49 AM, Steven Watanabe via Boost wrote:
(We really want the format to be memorialised for all time, regardless of future changes to the test system). It should be pretty simple to set up for portable archive formats.
Right. I'm not even sure it could be done for binary archives given the evolution in compilers/libraries etc.
Actually, I think you could make it work, if you make the key a list of the sizes of all known built in types + various standard typedefs (size_t, ptrdiff_t, streamsize). New toolchains that change any of this will automatically go into a new bin. We can at least guarantee that the archives are readable between ABI compatible toolchains (which is the most that we can reasonably expect for binary archives).
The main problem that I see is sorting out which binary archive is for the current platform.
since binary archives are not likely to be used for longer term storage, the problem would/could be ignored for this case. Of course someone would raise the issue about using serialization to pass data on the wire between different versions of the application.
This is all quite interesting. But I'm inclined to just accept the fact that I/we can't solve every problem. The number of cases that this problem has actually occurred is pretty small, especially when
Since I burned myself on this in a bad way in may 2010, the number of cases that this problem has actually occurred is very, very small. Somehow I'm thinking that it won't happen to Mr. King again at least.
In Christ, Steven Watanabe
Much of the issue I'm trying to fix could have been avoided if the serialization code in date_time had static assertions on the size of each field being written. I added that, and I recommend everyone else add the same to their serialization implementations. Something interesting happened with my pull request. On my local msvc-14.1 system I added some test checks for binary serialization of date_time. Version 0 is 62 bytes and version 1 is 74 bytes. 12 bytes makes sense since a field used three times was changed from boost::int32_t to boost::int64_t. That said, my builds on Travis CI all failed, claiming the size is 66 and not 62! See: https://travis-ci.org/boostorg/date_time/jobs/320724282#L1558 This leads me to wonder if serialization is compatible across platforms and if it is *supposed *to be compatible across platforms. Is this a bug?? Shouldn't binary serialization be the same size on every platform, assuming platform- specific types are not used? (Maybe that's the issue, perhaps not every type is platform-agnostic, I wonder if date_time documentation makes any claims to cross-platform binary serialization, or if one is supposed to use text or xml serialization always to achieve this). - Jim