On Oct 29, 2014, at 8:29 AM, Robert Ramey wrote:

Marshall Clow-2 wrote

...

...

boost serialization is still broken(said so: http://article.gmane.org/gmane.comp.lib.boost.user/82715 ) and to date i do know no workaround to get my library to work on fx Arch Linux without telling users to rebuild with boost 1.55 (or sending them a saved package from my system…)

This is news to me. I can't find a trac item on it. All tests of polymorphic archives are passing.

I pulled this from a mail message from the RC1 discussion (sorry for the poor summarization):

Message-ID: <54463F97.6000008@ruhr-uni-bochum.de> Date: Tue, 21 Oct 2014 13:12:23 +0200 From: oswin krause To: boost-users@lists.boost.org Subject: Re: [Boost-users] 1.57.0 beta 1 release candidates available for testing

boost serialization is still broken(said so: http://article.gmane.org/gmane.comp.lib.boost.user/82715 ) and to date i do know no workaround to get my library to work on fx Arch Linux without telling users to rebuild with boost 1.55 (or sending them a saved package from my system...)

Error message:

In file included from /home/ulfi/Shark/include/shark/Data/Impl/Dataset.inl:39:0, from /home/ulfi/Shark/include/shark/Data/Dataset.h:56, from /home/ulfi/Shark/include/shark/Models/Clustering/Centroids.h:39, from /home/ulfi/Shark/src/Models/Centroids.cpp:35: /home/ulfi/include/boost/serialization/shared_ptr.hpp: In instantiation of 'void boost::serialization::load(Archive&, boost::shared_ptr<U>&, unsigned int) [with Archive = boost::archive::polymorphic_iarchive; T = shark::blas::matrix]': [ much more … ]

— Marshall

On Oct 29, 2014, at 8:38 AM, Marcel Raad wrote:

Marshall Clow writes:

...

...

range/detail/any_iterator.hpp is broken because it expects postfix_increment_proxy and writable_postfix_increment_proxy to be in namespace boost::detail, but they are in boost::iterators::detail now.

This does NOT appear to have been fixed

This has been fixed in develop with https://github.com/boostorg/range/pull/17, but hasn't been merged to master yet.

That was pulled back in July. Is there any reason that it should not be merged to master? If not, please do so. — Marshall

On Wednesday 29 October 2014 11:14:12 Tom Kent wrote:

On Wed, Oct 29, 2014 at 9:50 AM, Marshall Clow

wrote:

...

We’ll be closing the master branch tomorrow (Thursday) for the 1.57.0 release. Changes not in by then will not go into the release.

Also, what issues in the beta have not been addressed?

There were failures building log for msvc-8.0 that did not exist in 1.56. Has anyone looked at these?

32 bit - http://pastebin.com/E3jkw44s 64 bit - http://pastebin.com/uAVJnPjY

I haven't seen these. And I cannot see these errors in the test matrix. From the first glance, this looks like something related to Boost.Move, but I'll have to look closer.

On Wednesday 29 October 2014 23:16:46 you wrote:

On Wednesday 29 October 2014 21:47:02 you wrote:

...

On Wednesday 29 October 2014 11:14:12 Tom Kent wrote:

...

On Wed, Oct 29, 2014 at 9:50 AM, Marshall Clow

wrote:

...

We’ll be closing the master branch tomorrow (Thursday) for the 1.57.0 release. Changes not in by then will not go into the release.

Also, what issues in the beta have not been addressed?

There were failures building log for msvc-8.0 that did not exist in 1.56. Has anyone looked at these?

32 bit - http://pastebin.com/E3jkw44s 64 bit - http://pastebin.com/uAVJnPjY

I haven't seen these. And I cannot see these errors in the test matrix. From the first glance, this looks like something related to Boost.Move, but I'll have to look closer.

Ok, apparently there are 2 problems:

1. 'boost::rv<T>::rv' : cannot access private member declared in class 'boost::rv<T>'

X& operator= (BOOST_COPY_ASSIGN_REF(T) t)

BOOST_COPY_ASSIGN_REF(T) is not T const&, which matters if you pass t to another templated function - in my case, a templated constructor, which accepted rv<T> const& in one of the overloads. This is probably a bug in my code (the constructor should accept rv<T>& instead), but it's a big gotcha from Boost.Move. I'll commit a fix after I run some more tests.

2. error C2036: 'boost::type' : unknown size

This one doesn't make sense to me. Looks like compiler's roof is on fire, but I have no idea what causes it.

I've committed the fix.