- Boost - lists.boost.org

[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

Compile failure in boost.signals2 with latest clang, c++20 and libc++
by Richard Hodges 31 Oct '20

31 Oct '20

Details in the linked issue: https://github.com/boostorg/signals2/issues/46 -- Richard Hodges

1 0

[Algorithm] Implementing: Find Longest Palindromic Substring(Sub-vector).
by Kanishk 31 Oct '20

31 Oct '20

Hello all, I'm new to the Boost community and this is my first time posting to the mailing group. What brought me here: I'm a Computer Science student and I often have to code up string/sequence related algorithms. An algorithm that I found was missing from the boost libraries was "Find Longest Palindromic Substring(or generic Sub-vector)". Boost has *is_palindrome *( https://www.boost.org/doc/libs/1_66_0/boost/algorithm/is_palindrome.hpp) but using that to check every possible substring will result in an O(N^3) runtime. It is trivial to implement an O(N^2) algorithm for this purpose using dynamic-programming. It is also possible to implement this in O(N) using the Manacher's algorithm ( https://en.wikipedia.org/wiki/Longest_palindromic_substring#Manacher's_algorithm ). Will this be a useful addition to the Boost.Algorithm library? If so, I would love to start contributing to boost through this. Regards, Kanishk

1 0

[histogram][type_traits] strange compile error in boost.histogram for gcc-7.1+ with -std=c++17; possible bug in gcc?
by Hans Dembinski 30 Oct '20

30 Oct '20

Dear John and the other gurus, a strange bug was reported for Boost.Histogram. It is a difficult one for which I would like to ask for help. To me it looks like a bug in gcc. Here is the issue: https://github.com/boostorg/histogram/issues/290 And here is a link to reproduce it: https://godbolt.org/z/oK4866 The following innocent code compiled with gcc-7.1 or newer with -std=c++17 ``` #include <boost/type_traits/rank.hpp> #include <boost/histogram/axis/traits.hpp> int main() { return 0; } ``` produces this error message (excerpt): ``` cc1plus: error: return type specified for deduction guide In file included from <source>:2: /celibs/boost_1_74_0/boost/histogram/axis/traits.hpp:411:11: error: 'decl-specifier' in declaration of deduction guide 411 | constexpr unsigned rank(const Axis& axis) { | ^~~~~~~~ /celibs/boost_1_74_0/boost/histogram/axis/traits.hpp:411:1: error: 'decl-specifier' in declaration of deduction guide 411 | constexpr unsigned rank(const Axis& axis) { | ^~~~~~~~~ /celibs/boost_1_74_0/boost/histogram/axis/traits.hpp:411:11: error: 'unsigned' specified with 'rank<...auto...>' 411 | constexpr unsigned rank(const Axis& axis) { | ^~~~~~~~ /celibs/boost_1_74_0/boost/histogram/axis/traits.hpp:411:20: error: deduction guide for 'boost::rank<T>' must have trailing return type 411 | constexpr unsigned rank(const Axis& axis) { | ^~~~ In file included from <source>:1: /celibs/boost_1_74_0/boost/type_traits/rank.hpp:82:27: note: 'template<class T> struct boost::rank' declared here 82 | template <class T> struct rank : public integral_constant<std::size_t, (::boost::detail::rank_imp<T, 0>::value)>{}; | ^~~~ ``` gcc interprets my function called `rank` as a deduction guide for `boost::rank` in boost/type_traits/rank.hpp. It then continues to complain that this function does not look like a deduction guide. Well, it isn't one, duh. I can see nothing wrong with my code or the code in boost/type_traits, so my guess is a bug in gcc. If you all agree, I would report this. If this is really a bug in gcc, however, it exists since v7.1 all the way to gcc trunk. In either case, it would be great if we could use a workaround in Boost until that problem is fixed. I found a workaround is to replace line 82 in boost/type_traits/rank.hpp with: ``` template <class T> using rank = integral_constant<std::size_t, (::boost::detail::rank_imp<T, 0>::value)>; ``` This avoids the issue because now the struct ``rank`` is gone and therefore gcc does not try to find a deduction guide for it. Is there a better solution? Best regards, Hans

3 4

[gil] Phasing out support C++11 and switching to C++17
by Mateusz Loskot 27 Oct '20

27 Oct '20

Hi, We're discussing [1] to start switching GIL to C++17 in the near future and, following Peter Dimov's policy on phasing out C++XY support [2], we'd like to: 1. Declare C++11 support deprecated in 1.75 (December 2020) 2. Drop C++11 support in 1.77 (?) (August 2021) Could anyone help us validate and confirm that it's a good plan or are we overlooking any policies from Boost's release perspective? [1] https://lists.boost.org/boost-gil/2020/10/0465.php [2] https://pdimov.github.io/articles/phasing_out_cxx03.html Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

7 18