November 2020 - Boost - lists.preview.boost.org

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

[release] Reminder: Master branch closes for the 1.75.0 beta THIS WEDNESDAY
by Marshall Clow 02 Nov '20

02 Nov '20

See the calendar here for more dates: https://www.boost.org/development/ <https://www.boost.org/development/> The master branch will be re-opened after the beta release. Thanks, — The Boost Release Team

1 0