- Boost - lists.boost.org

[release] Fixing Boost.Rational and boost/operators.hpp infinite loop in C++20 by 1.75
by Glen Fernandes 16 Nov '20

16 Nov '20

We have a problem with Boost.Rational and <boost/operators.hpp> in Boost.Utility in C++20 standards mode. I've fixed Boost.Rational in develop. Relevant GitHub issues: 1. https://github.com/boostorg/rational/issues/43 2. https://github.com/boostorg/utility/issues/65 My fix for Boost.Rational that I will merge to master for the 1.75 release: https://github.com/boostorg/rational/pull/45 The root cause is the same. C++20 adds new language rules that implicitly generate some operators, and the current implementations result in an infinite loop. (In both cases an equality operator ends up calling itself recursively). GCC does emit a warning diagnostic in C++20 mode, but as usual these tend to be unnoticed at build time. ../../boost/rational.hpp:779:16: warning: in C++20 this comparison calls the current function recursively with reversed arguments 779 | return a == b; | ~~^~~~ So this issue was found by three independent users of Rational (one who reported a Github issue, the other who complained on Reddit, and a third that tried running the Rational unit tests with GCC10 and found two failures). <boost/operators.hpp> in Boost.Utility still needs a fix for C++20 mode, but it has an active maintainer unlike Rational. The GitHub issue for it was closed (I've reopened it) because it was assumed to be a defect in the standard and one that vendors would fix. We did have some discussion on the C++ standard committee reflector about this, however - whatever the future change to the standard is - GCC and Clang with -std=c++20 that implement these rules have already been released and users are using it, so we should fix this in Boost 1.75. Glen

2 1

Re: [boost] [release] 1.75.0 post-beta merges
by Glen Fernandes 16 Nov '20

16 Nov '20

Robert Ramey wrote: > request permission to sync changes in develop into master for > two libraries: serialization and safe_numerics. They've been ready for > some time, I just forgot to do it in time. Go ahead. Glen

1 0

[release] Boost 1.74.0 beta 1 released
by Marshall Clow 14 Nov '20

14 Nov '20

Boost release 1.75.0 beta 1 is now available at: <https://dl.bintray.com/boostorg/beta/1.75.0.beta1/source/> The SHA256 checksums are as follows: 3f01d3e5dc822e151892040d4667e364ea808d208d2e49cc7a1802bd4da3d4cc boost_1_75_0_b1.7z 9b75a80f845d4ae312e3c9151ffdfe3fed450973095e0a15c68d0be394f2f2df boost_1_75_0_b1.tar.bz2 123519d4b056fbbd69e452db880abe2c7e55f21779d44a4d6b6c714d5c13c3ee boost_1_75_0_b1.tar.gz b73e01d22d5b3d2ff82f14a371e3974fab30448bf6ff5ac8b9c829539a19c2d7 boost_1_75_0_b1.zip For details of what's in the release, see <https://www.boost.org/users/history/version_1_75_0.html>. Please download the beta, give it a try, and report any problems you encounter. Thanks, -- The Boost Release Team

1 0

Boost.Exception regression in 1.75.0 beta 1
by Niall Douglas 14 Nov '20

14 Nov '20

If you diagnose the test failures (which are present across all compilers) in https://www.boost.org/development/tests/develop/developer/outcome.html which report failures of the form: ``` unknown location(0): fatal error: in "works_outcome": Throw location unknown (consider using BOOST_THROW_EXCEPTION) Dynamic exception type: struct boost::wrapexcept<class boost::exception_ptr> libs\outcome\test\tests\core-outcome.cpp(173): last checkpoint *** 1 failure is detected in the test module "Outcome" ``` The cause is test code such as: ``` boost::system::error_code ec(5, boost::system::system_category()); auto e = boost::copy_exception(boost::system::system_error(ec)); // NOLINT outcome<int> m(e); BOOST_CHECK_THROW(m.value(), boost::system::system_error); ``` Outcome calls boost::rethrow_exception() to rethrow the exception_ptr. boost::rethrow_exception() is not rethrowing the boost::system::system_error held within the boost::exception_ptr. It is throwing instead boost::wrapexcept<class boost::exception_ptr>. This causes BOOST_CHECK_THROW() to not correctly trap the type of exception thrown, and thus the test fails. boost::wrapexcept<E> inherits from E. It seems to me therefore that catching a const E& ought to catch throws of boost::wrapexcept<E>, and therefore this code is correct. I double checked this at https://wandbox.org/permlink/n9Wjb5cPpfHEFalp, and indeed it works as expected. However, obviously enough this is failing, and it was not failing in Boost 1.74, so this is a regression. I am stumped as to the exact cause. This affects all platforms, POSIX, Windows, clang, GCC and MSVC. Niall

3 2

permission to merge fix
by Oliver Kowalke 08 Nov '20

08 Nov '20

Do I get permission to merge a fix related to boostorg/fiber#264 <https://github.com/boostorg/fiber/issues/264> into master? Oliver

3 3

[release] Boost 1.75.0 Beta 1 Release Candidate 1
by Marshall Clow 07 Nov '20

07 Nov '20

The first release candidates for the 1.75.0 beta release are now available at: <https://dl.bintray.com/boostorg/release/1.75.0.beta1/source/> The SHA256 checksums are as follows: c271f488c7c8de7c147bf8675d578fb2f06c6c171d9547c5a40cddccb9f2a6c4 boost_1_75_0_b1_rc1.7z 0db0944e9d2250907e011900eea304ca055d1c418d38b3fbb1eee692a6b851a6 boost_1_75_0_b1_rc1.tar.bz2 624bd6b03d86bf1387b4e8927dab16b4198f255f15dd71d6a8c1c5ec270584b3 boost_1_75_0_b1_rc1.tar.gz 07ddca7c39ea9152bad73bee4f10f2c9c8e3a2d7e153aa945a343f83eca5db59 boost_1_75_0_b1_rc1.zip 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. -- The Release managers

3 6

[1.75 release] Merging 'develop' to 'master' for Embarcadero fix
by Edward Diener 06 Nov '20

06 Nov '20

A number of libraries have my PR to enable Embarcadero C++ clang-based compilers for Boost in their 'develop' branch but the branch has not been merged to 'master' for the 1.75 release. In the large majority of cases my PR for Embarcadero is the only difference between 'develop' and 'master'. These libraries are: assign circular_buffer container_hash date_time foreach graph iostreams numeric_conversion optional pool ptr_container random static_assert thread typeof units unordered If any of the maintainers of these libraries could see fit to get my PR in 'master' from 'develop' for the 1.75 release, it would be appreciated. I can assert that the PR causes no problems in the 'develop' regression tests for the aforementioned libraries. I have also opened up an issue for each of the aforementioned libraries in their Github page regarding my request.

7 18

[release] Master branch now closed for 1.75.0 beta release
by Marshall Clow 06 Nov '20

06 Nov '20

Please do not make any commits to the master branch.

1 0

1.75 schedule reminder
by Peter Dimov 03 Nov '20

03 Nov '20

A reminder that Oct 21 was the cutoff date for new library additions, and the upcoming deadlines are - Oct 28: Boost 1.75.0 closed for major changes - Nov 4: Boost 1.75.0 closed for beta - Nov 11: Boost 1.75.0 beta - Dec 2: Boost 1.75.0 closed for release - Dec 9: Boost 1.75.0 release (See the calendar at https://www.boost.org/development/index.html.)

5 4

sticky question regarding boost rational
by Robert Ramey 02 Nov '20

02 Nov '20

boost rational is tripping up one of my examples in safe numerics: // solution: use safe integer in rational definition using safe_rational = boost::rational< boost::safe_numerics::safe<int> >; // use rationals created with safe_t const safe_rational sc {1, std::numeric_limits<int>::max()}; std::cout << "c = " << sc << std::endl; const safe_rational sd {1, 2}; std::cout << "d = " << sd << std::endl; std::cout << "c * d = "; try { // multiply them. This will overflow std::cout << sc * sd << std::endl; // use of overload operator * is ambiguous. rational.hpp contains - among other things, the following definitions for the * operator: template <class IntType, class Arg> BOOST_CXX14_CONSTEXPR inline typename boost::enable_if_c < rational_detail::is_compatible_integer<Arg, IntType>::value || is_same<rational<IntType>, Arg>::value, rational<IntType> >::type operator * (const rational<IntType>& a, const Arg& b) { rational<IntType> t(a); return t *= b; } template <class Arg, class IntType> BOOST_CXX14_CONSTEXPR inline typename boost::enable_if_c < rational_detail::is_compatible_integer<Arg, IntType>::value, rational<IntType> >::type operator * (const Arg& b, const rational<IntType>& a) { rational<IntType> t(a); return t *= b; } Soooooo - it seems that sc * sd will match both of the above definitions. Its unclear what the purpose of these two different overloads are. They look pretty similar to me. the definition for is_compatible_integer. namespace rational_detail{ template <class FromInt, class ToInt, typename Enable = void> struct is_compatible_integer; template <class FromInt, class ToInt> struct is_compatible_integer<FromInt, ToInt, typename enable_if_c<!is_array<FromInt>::value>::type> { BOOST_STATIC_CONSTANT(bool, value = ((std::numeric_limits<FromInt>::is_specialized && std::numeric_limits<FromInt>::is_integer && (std::numeric_limits<FromInt>::digits <=std::numeric_limits<ToInt>::digits) && (std::numeric_limits<FromInt>::radix == std::numeric_limits<ToInt>::radix) && ((std::numeric_limits<FromInt>::is_signed == false) || (std::numeric_limits<ToInt>::is_signed == true)) && is_convertible<FromInt, ToInt>::value) || is_same<FromInt, ToInt>::value) || (is_class<ToInt>::value && is_class<FromInt>::value && is_convertible<FromInt, ToInt>::value)); }; ... In fact, since it looks like if FromInt and ToInt are the same types (as they are in my case, one will always got more than one match. Is anyone (John Maddock - where are you?) able to shed some light on this for me? Robert Ramey

2 1