Boost logo

Boost :

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 <
boost_at_[hidden]> wrote:

> 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
or xml
serialization always to achieve this).

- Jim

Boost list run by bdawes at, gregod at, cpdaniel at, john at