Subject: Re: [boost] Candidate for 1.66.1, if there is one
From: James E. King, III (jking_at_[hidden])
Date: 2017-12-24 16:42:24
On Sat, Dec 23, 2017 at 4:54 PM, Steven Watanabe via Boost <
> 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
code in date_time had static assertions on the size of each field being
I added that, and I recommend everyone else add the same to their
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.
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
my builds on Travis CI all failed, claiming the size is 66 and not 62! See:
This leads me to wonder if serialization is compatible across platforms and
it is *supposed *to be compatible across platforms. Is this a bug??
binary serialization be the same size on every platform, assuming platform-
specific types are not used? (Maybe that's the issue, perhaps not every
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
serialization always to achieve this).
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk