- Boost - lists.preview.boost.org

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

[pfr] Ready for informal mini review
by Antony Polukhin 20 Oct '20

20 Oct '20

Hi, Issues noted during the review period were fixed. Mainly: * global_ops.hpp is removed * boost::pfr::ops::operator* were changed to functions and moved to boost::pfr:: namespace * Flat reflection was purged * Big rewrite of docs I'd appreciate a look at the updated library https://github.com/boostorg/pfr and its docs https://apolukhin.github.io/magic_get/index.html Any comments and feedback is welcomed! -- Best regards, Antony Polukhin

2 3

Re: [boost] [pfr] Ready for informal mini review
by Glen Fernandes 20 Oct '20

20 Oct '20

Antony Polukhin wrote: > I'd appreciate a look at the updated library > > https://github.com/boostorg/pfr and its docs > https://apolukhin.github.io/magic_get/index.html > > Any comments and feedback is welcomed! Note that the last day for new libraries for Boost 1.75 is tomorrow (2020-10-21). PFR has a develop submodule, but no master submodule yet. I was waiting until you believe it is ready, and have ironed out all the issues on develop. If you want it included in the 1.75 release, and there are no objections from any reviewers, I can add the master submodule today. (It was already added to the in-progress release notes for 1.75, but that can be removed if you don't want to release it until 1.76). Glen

2 2

[FPR] Review of FPR starts Today: Sept 28 - Oct 7
by Benedek Thaler 16 Oct '20

16 Oct '20

The Boost formal review of the FPR (Flat Precise Reflection, ex Magic Get, ex PODs Flat Reflection) starts Today, taking place from September 28, 2020 to October 7, 2020. The library is authored by Antony Polukhin, author of Boost.DLL, Stacktrace, Type Index libraries. Documentation: http://apolukhin.github.io/magic_get/ Source: https://github.com/apolukhin/magic_get The library is meant for accessing structure elements by index and providing other std::tuple like methods for user defined types without any macro or boilerplate code. The FPR documentation summarizes the out-of-the-box added functionality for aggregate initializable structures: - comparison operators - heterogeneous comparators - hash - stream operators - access to members by index - member reflections - methods for cooperation with std::tuple - methods to visit each field of the structure If the description isn't immediately obvious for you, here's a motivating example: // requires: C++14 #include <iostream> #include <string> #include "boost/pfr/precise.hpp" struct some_person { std::string name; unsigned birth_year; }; int main() { some_person val{"Edgar Allan Poe", 1809}; std::cout << boost::pfr::get<0>(val) // No macro! << " was born in " << boost::pfr::get<1>(val); // Works with any aggregate initializables! } Please provide in your review information you think is valuable to understand your choice to ACCEPT or REJECT including FPR as a Boost library. Please be explicit about your decision (ACCEPT or REJECT). Some other questions you might want to consider answering: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With which compiler(s)? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? More information about the Boost Formal Review Process can be found at: http://www.boost.org/community/reviews.html Thank you for your effort in the Boost community. Benedek - review manager of the FPR library

8 12