Boost 1_58_0_b1_rc2 is available for testing
Release candidate files for 1.58.0 beta 1 are available at http://boost.cowic.de/rc/ As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. This helps ensure the candidates build OK before we push them out to SourceForge. Changes since rc1: * Added the new libraries endian, sort, and winapi. IMPORTANT NOTE: There is a bug with the build scripts; you have to specify the address-mode and architecture to b2. I used: ./b2 address-model=64 architecture=x86 to test this. The files (and associated md5s) are: MD5 (boost_1_58_0_b1_rc2.7z) = c58623e8c3d48154bdb1fa2ee5cdbfab MD5 (boost_1_58_0_b1_rc2.tar.bz2) = 94480c2d9de3804a1a4b626a7828bec0 MD5 (boost_1_58_0_b1_rc2.tar.gz) = f7d4b398388c13ca30960c92b8d6342f MD5 (boost_1_58_0_b1_rc2.zip) = 2e9bdfd8dab269a69e4ea4e5ae5b6d47 Thanks! -- The release managers
On Fri, Mar 13, 2015 at 12:51 PM Marshall Clow <mclow.lists@gmail.com> wrote:
Release candidate files for 1.58.0 beta 1 are available at http://boost.cowic.de/rc/
I found a broken backup doc link in the inspect report (the default refresh works fine, which is why I didn't spot it earlier), and fixed it in https://github.com/boostorg/sort/ (both master and develop). Do I need to do anything additional to make sure the doc fix will be included in the final release?
I don't know - ask Daniel James Daniel James <dnljms@gmail.com> and/or Marshall Clow <mclow.lists@gmail.com> ??? Paul
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Steven Ross Sent: 14 March 2015 01:53 To: boost@lists.boost.org Subject: Re: [boost] Boost 1_58_0_b1_rc2 is available for testing
On Fri, Mar 13, 2015 at 12:51 PM Marshall Clow <mclow.lists@gmail.com> wrote:
Release candidate files for 1.58.0 beta 1 are available at http://boost.cowic.de/rc/
I found a broken backup doc link in the inspect report (the default refresh works fine, which is why I didn't spot it earlier), and fixed it in https://github.com/boostorg/sort/ (both master and develop). Do I need to do anything additional to make sure the doc fix will be included in the final release?
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Fri, Mar 13, 2015 at 9:51 AM, Marshall Clow <mclow.lists@gmail.com> wrote:
Release candidate files for 1.58.0 beta 1 are available at http://boost.cowic.de/rc/
As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy.
Looks good on windows. Tom toolset arch compile install Link Execute msvc-8.0 32 X X X X msvc-8.0 64 X X X X msvc-9.0 32 X X X X msvc-9.0 64 X X X X msvc-10.0 32 X X X X msvc-10.0 64 X X X X msvc-11.0 32 X X X X msvc-11.0 64 X X X X msvc-12.0 32 X X X X msvc-12.0 64 X X X X Compile means that the b2 command completed without errors Install means that the installers for the respective version were generated Link means that visual studio was able to link a sample executable to a library (libboost_thread-vcXXX-mt[-gd]-1_XX.lib) generated Execute means that the linked program executed without errors.
On 3/13/2015 9:51 AM, Marshall Clow wrote: > Release candidate files for 1.58.0 beta 1 are available at > http://boost.cowic.de/rc/ > > As always, the release managers would appreciate it if you download > the candidate of your choice and give building it a try. Please report > both success and failure, and anything else that is noteworthy. It's much better than b1rc1. I managed to build nuget packages for VS100/VS110/VS120/VS140ctp6: - https://getboost.codeplex.com/releases/view/612519 (headers and sources HPP/CPP) - https://getboost.codeplex.com/releases/view/612520 (pre-compiled libraries LIB/DLL) I noticed that contex library hasn't been built for VS140 CTP6. I haven't look the build log yet. Best regards, Sergey Shandar.
Sergey Shandar <sergey.shandar <at> gmail.com> writes:
I noticed that contex library hasn't been built for VS140 CTP6. I haven't look the build log yet.
This is due to a compiler bug that has already been fixed in the online version of VC14.
Marshall Clow <mclow.lists <at> gmail.com> writes:
As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy.
I get a lot of compile errors on MSVC12 when using boost::bind with more than two arguments of which one is a non-const reference and constructing a boost::function with the result: #include <boost/bind.hpp> #include <boost/function.hpp> void a(int&, int, int); int main(){ boost::function<void(int&, int, int)> f(boost::bind(&a, _1, _2, _3)); } results in error C2664: 'void (int &,int,int)': cannot convert argument 1 from 'const int' to 'int &' There are no compile errors with only one or two arguments of which one is a reference, and "auto f = boost::bind(...)" compiles too.
Marcel Raad wrote:
I get a lot of compile errors on MSVC12 when using boost::bind with more than two arguments of which one is a non-const reference and constructing a boost::function with the result:
#include <boost/bind.hpp> #include <boost/function.hpp>
void a(int&, int, int);
int main(){ boost::function<void(int&, int, int)> f(boost::bind(&a, _1, _2, _3)); }
results in error C2664: 'void (int &,int,int)': cannot convert argument 1 from 'const int' to 'int &'
Good one. This regression is caused by the following change to boost::function: https://github.com/boostorg/function/commit/27e9e1e372df203186a9e89e887a4e10... You can verify that by adding #include <boost/config.hpp> #define BOOST_NO_CXX11_RVALUE_REFERENCES at the top of the source file. An example that doesn't use boost::bind is: int main() { boost::function<void(int, int, int)> f2( &a ); } This, too, worked before the change and doesn't now.
AMDG On 03/14/2015 03:51 PM, Peter Dimov wrote:
An example that doesn't use boost::bind is:
int main() { boost::function<void(int, int, int)> f2( &a ); }
This, too, worked before the change and doesn't now.
One of these has to fail: int ref(int&); int rref(int&&); boost::function<void(int)> f1(&ref); boost::function<void(int)> f2(&rref); I don't think there's any strong reason to support one over the other, so it's probably best to allow f1, since it used to be supported before rvalue references. The attached patch should work. I've tested it with msvc 9-12 and gcc 4.8 c++03 and c++11. If no one objects, I'll commit this to develop. In Christ, Steven Watanabe
[Steven Watanabe]
One of these has to fail: int ref(int&); int rref(int&&); boost::function<void(int)> f1(&ref); boost::function<void(int)> f2(&rref); I don't think there's any strong reason to support one over the other
The Standard says that f1 is ill-formed for std::function (and this is properly rejected by my overhauled <functional> in VC 2015; I'd assume that libstdc++ and libc++ also reject). STL
AMDG On 03/17/2015 04:38 PM, Stephan T. Lavavej wrote:
[Steven Watanabe]
One of these has to fail: int ref(int&); int rref(int&&); boost::function<void(int)> f1(&ref); boost::function<void(int)> f2(&rref); I don't think there's any strong reason to support one over the other
The Standard says that f1 is ill-formed for std::function (and this is properly rejected by my overhauled <functional> in VC 2015; I'd assume that libstdc++ and libc++ also reject).
So is it more important to match std::function or to avoid breaking existing code? In Christ, Steven Watanabe
[Steven Watanabe]
So is it more important to match std::function or to avoid breaking existing code?
That's your call. Over in the Standard Library, I ruthlessly deliver conformance and breaking changes (especially at compile-time like this). Note that this affects signatures like function<void (unique_ptr<int>)>, which work for std::function. In general, my motto is that INVOKE is scary, so I should do exactly what it says, so INVOKE gets all the blame if users are unhappy. (It's actually well-designed, just deeply scary.) STL
Stephan T. Lavavej wrote:
[Steven Watanabe]
So is it more important to match std::function or to avoid breaking existing code?
That's your call. Over in the Standard Library, I ruthlessly deliver conformance and breaking changes (especially at compile-time like this).
The problem here is that on compilers that don't support rvalue references, the code works, and on those that do, it fails. It's a bit of an annoyance. It should be noted, however, that the problem in the original example is also caused by boost::bind not doing perfect forwarding, so perhaps this is what needs to be fixed. But I'm not sure that now (between beta an release) is the time to do that.
Note that this affects signatures like function<void (unique_ptr<int>)>, which work for std::function. In general, my motto is that INVOKE is scary, so I should do exactly what it says, so INVOKE gets all the blame if users are unhappy. (It's actually well-designed, just deeply scary.)
It's not INVOKE that causes the problem, but the std::forward<ArgTypes>(args)... part. If you INVOKE( f, args..., R ) instead, as boost::function used to do, it will work.
[Peter Dimov]
The problem here is that on compilers that don't support rvalue references, the code works, and on those that do, it fails. It's a bit of an annoyance.
Compilers that don't support rvalue references? Such things don't exist. :-> Speaking as someone who's worked on a Standard Library through the TR1/0x/11/14 upgrade process, I've observed that users are far more likely to complain that their movable-only types aren't being respected, than that their old code is failing to compile. STL
Steven Watanabe wrote:
One of these has to fail:
int ref(int&); int rref(int&&);
boost::function<void(int)> f1(&ref); boost::function<void(int)> f2(&rref);
I don't think there's any strong reason to support one over the other, so it's probably best to allow f1, since it used to be supported before rvalue references.
The rationale for supporting f1 was that void f1( int x ) { return ref( x ); } works, and this is what boost::function was, conceptually, trying to provide. Of course, this decision to allow f1(&ref) was made before rvalue references. Nowadays one would argue that rref should be free to pilfer the argument for efficiency.
Marcel Raad wrote:
I get a lot of compile errors on MSVC12 when using boost::bind with more than two arguments of which one is a non-const reference and constructing a boost::function with the result:
#include <boost/bind.hpp> #include <boost/function.hpp>
void a(int&, int, int);
int main(){ boost::function<void(int&, int, int)> f(boost::bind(&a, _1, _2, _3)); }
results in error C2664: 'void (int &,int,int)': cannot convert argument 1 from 'const int' to 'int &'
Thank you, Marcel, for reporting this. I added a test in https://github.com/boostorg/bind/commit/b4881265fbe2100211a7ffb734ce2aaa0d00... and then fixed it in https://github.com/boostorg/bind/commit/42b5cef177603328ead66bc6a98a3067aebc... Would appreciate if you give this change a try and see if it has any unwanted consequences.
Peter Dimov <lists <at> pdimov.com> writes:
fixed it in
https://github.com/boostorg/bind/commit/42b5cef177603328ead66bc6a98a3067aebc 433d
Would appreciate if you give this change a try and see if it has any unwanted consequences.
Thanks a lot Peter, everything works as it did in 1.57! Tested with MSVC12 and MSVC14 and a few different projects. Unfortunately I found a new problem in Boost.Optional. I get weird compile errors in one project, both with MSVC12 and MSVC14: error C3083: ' ?? A0x6071e18f': the symbol to the left of a '::' must be a type for a line declaring a member function with a boost::optional parameter with a default value of boost::none. BOOST_OPTIONAL_USE_OLD_DEFINITION_OF_NONE fixes the problem. Unfortunately I haven't been able to find a minimal example to replicate the problem yet - calling that function from two compilation units is not enough.
Marcel Raad <raad <at> teamviewer.com> writes:
Unfortunately I found a new problem in Boost.Optional. I get weird compile errors in one project, both with MSVC12 and MSVC14: error C3083: ' ?? A0x6071e18f': the symbol to the left of a '::' must be a type
for a line declaring a member function with a boost::optional parameter with a default value of boost::none.
BOOST_OPTIONAL_USE_OLD_DEFINITION_OF_NONE
fixes the problem.
I've finally been able to reproduce the problem. It occurs only if <boost/optional.hpp> is in the precompiled headers.
On 14 March 2015 at 05:51, Marshall Clow <mclow.lists@gmail.com> wrote:
Release candidate files for 1.58.0 beta 1 are available at http://boost.cowic.de/rc/
As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy.
This helps ensure the candidates build OK before we push them out to SourceForge.
Changes since rc1: * Added the new libraries endian, sort, and winapi.
Can the patches for Haiku also be included? Some were only merged to develop. Pull requests: https://github.com/boostorg/filesystem/pull/8 https://github.com/boostorg/build/pull/51 The remainder, from what I can tell, have already been merged to master for the various modules.
On Mar 16, 2015, at 3:12 PM, Jessica Hamilton <jessica.l.hamilton@gmail.com> wrote:
On 14 March 2015 at 05:51, Marshall Clow <mclow.lists@gmail.com> wrote:
Release candidate files for 1.58.0 beta 1 are available at http://boost.cowic.de/rc/
As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy.
This helps ensure the candidates build OK before we push them out to SourceForge.
Changes since rc1: * Added the new libraries endian, sort, and winapi.
Can the patches for Haiku also be included? Some were only merged to develop.
Pull requests:
https://github.com/boostorg/filesystem/pull/8 https://github.com/boostorg/build/pull/51
The remainder, from what I can tell, have already been merged to master for the various modules.
Nope :-) But now that the beta has been released, you can merge them to master and then they will be included in the final 1.58 release (or the next beta, whichever comes first). — Marshall
On 17 March 2015 at 12:34, Marshall Clow <mclow.lists@gmail.com> wrote:
On Mar 16, 2015, at 3:12 PM, Jessica Hamilton <jessica.l.hamilton@gmail.com> wrote:
On 14 March 2015 at 05:51, Marshall Clow <mclow.lists@gmail.com> wrote:
Release candidate files for 1.58.0 beta 1 are available at http://boost.cowic.de/rc/
As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy.
This helps ensure the candidates build OK before we push them out to SourceForge.
Changes since rc1: * Added the new libraries endian, sort, and winapi.
Can the patches for Haiku also be included? Some were only merged to develop.
Pull requests:
https://github.com/boostorg/filesystem/pull/8 https://github.com/boostorg/build/pull/51
The remainder, from what I can tell, have already been merged to master for the various modules.
Nope :-)
But now that the beta has been released, you can merge them to master and then they will be included in the final 1.58 release (or the next beta, whichever comes first).
I'm not a committer... shall I just make a new PR from develop to master? I'm fairly new to the Boost community.
Date: Wed, 18 Mar 2015 09:58:55 +1300 From: jessica.l.hamilton@gmail.com To: boost@lists.boost.org Subject: Re: [boost] Boost 1_58_0_b1_rc2 is available for testing
On 17 March 2015 at 12:34, Marshall Clow <mclow.lists@gmail.com> wrote:
On Mar 16, 2015, at 3:12 PM, Jessica Hamilton <jessica.l.hamilton@gmail.com> wrote: https://github.com/boostorg/filesystem/pull/8 https://github.com/boostorg/build/pull/51
I'm not a committer... shall I just make a new PR from develop to master? I'm fairly new to the Boost community.
The filesystem pull request was to master rather than develop. Patches should always be made relative to develop, much like this pull request I just did based on yours: https://github.com/boostorg/filesystem/pull/10 At that point, Beman should be able to handle the rest.
On Tue, Mar 17, 2015 at 1:58 PM, Jessica Hamilton < jessica.l.hamilton@gmail.com> wrote:
On 17 March 2015 at 12:34, Marshall Clow <mclow.lists@gmail.com> wrote:
On Mar 16, 2015, at 3:12 PM, Jessica Hamilton <
jessica.l.hamilton@gmail.com> wrote:
On 14 March 2015 at 05:51, Marshall Clow <mclow.lists@gmail.com> wrote:
Release candidate files for 1.58.0 beta 1 are available at http://boost.cowic.de/rc/
As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy.
This helps ensure the candidates build OK before we push them out to SourceForge.
Changes since rc1: * Added the new libraries endian, sort, and winapi.
Can the patches for Haiku also be included? Some were only merged to
develop.
Pull requests:
https://github.com/boostorg/filesystem/pull/8 https://github.com/boostorg/build/pull/51
The remainder, from what I can tell, have already been merged to master for the various modules.
Nope :-)
But now that the beta has been released, you can merge them to master and then they will be included in the final 1.58 release (or the next beta, whichever comes first).
I'm not a committer... shall I just make a new PR from develop to master? I'm fairly new to the Boost community.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Jessica — In the general case, you would ping the maintainer of Boost.Pool and Boost.Filesystem to merge them. In the case of Boost.Pool. I will take care of it, since Steven Cleary hasn’t been heard from for a while. Beman Dawes is the maintainer of Boost.Filesystem, and I have cc’ed him on this email. — Marshall
On Wed, Mar 18, 2015 at 11:01 AM, Marshall Clow <mclow.lists@gmail.com> wrote:
Jessica —
In the general case, you would ping the maintainer of Boost.Pool and Boost.Filesystem to merge them. In the case of Boost.Pool. I will take care of it, since Steven Cleary hasn’t been heard from for a while. Beman Dawes is the maintainer of Boost.Filesystem, and I have cc’ed him on this email.
Sorry, I misread the pull URLs. There’s nothing there for Boost.Pool, but I’ve pinged Vlad about the Boost.Build request. — Marshall
Hi, On 2015-03-13 17:51, Marshall Clow wrote:
Release candidate files for 1.58.0 beta 1 are available at http://boost.cowic.de/rc/
As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy.
I build boost for QNX/Blackberry10 (with Dinkum lib) and I found some compile issues. Some minor thinks for example in boost/smart_ptr/detail/array_allocator.hpp is a missing std:: namespace on ptrdiff_t. Some problems I think, triggers a discussions for example in boost/archive/archive_exception.hpp is a throw() declaration on destructor but on boost::archive::xml_archive_exception::~xml_archive_exception() not (it inherited archive_exception). Should I create a new ticket in the bug tracker and it is possible that the issues are fixed in 1.58.0 release? Thanks Jörg
On 19 Mar 2015 at 11:38, Jörg Böhme wrote:
I build boost for QNX/Blackberry10 (with Dinkum lib) and I found some compile issues. Some minor thinks for example in boost/smart_ptr/detail/array_allocator.hpp is a missing std:: namespace on ptrdiff_t. Some problems I think, triggers a discussions for example in boost/archive/archive_exception.hpp is a throw() declaration on destructor but on boost::archive::xml_archive_exception::~xml_archive_exception() not (it inherited archive_exception).
Should I create a new ticket in the bug tracker and it is possible that the issues are fixed in 1.58.0 release?
Tag it with bb10/qnx like the above. Tony should spot it shortly. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
Jörg Böhme wrote:
I build boost for QNX/Blackberry10 (with Dinkum lib) and I found some compile issues. Some minor thinks for example in boost/smart_ptr/detail/array_allocator.hpp is a missing std:: namespace on ptrdiff_t. ... Should I create a new ticket in the bug tracker...
Yes please. A pull request (against the develop branch) would be even better.
and it is possible that the issues are fixed in 1.58.0 release?
That would depend on the release managers.
On 2015-03-19 14:34, Peter Dimov wrote:
Jörg Böhme wrote:
I build boost for QNX/Blackberry10 (with Dinkum lib) and I found some compile issues. Some minor thinks for example in boost/smart_ptr/detail/array_allocator.hpp is a missing std:: namespace on ptrdiff_t. ... Should I create a new ticket in the bug tracker...
Yes please. A pull request (against the develop branch) would be even better.
I create ticket: 11127 + 11128 + 11129 + 11130 + 11131 and pull requests: https://github.com/boostorg/serialization/pull/11 https://github.com/boostorg/test/pull/42 https://github.com/boostorg/msm/pull/4 https://github.com/boostorg/property_tree/pull/8 https://github.com/boostorg/smart_ptr/pull/14 So I hope I did it right. Thanks Jörg
participants (13)
-
Ahmed Charles -
Jessica Hamilton -
Jörg Böhme -
Marcel Raad -
Marshall Clow -
Niall Douglas -
Paul A. Bristow -
Peter Dimov -
Sergey Shandar -
Stephan T. Lavavej -
Steven Ross -
Steven Watanabe -
Tom Kent