- Boost - lists.boost.org

[Bimap] Maintenance
by Matias Capeletto 21 May '20

21 May '20

Hello Some Boost.Bimap's maintenance PRs have remained unmerged. The library also hasn't been following additions to the STL that should be mapped in the provided containers and implementing proper support for move semantics, between other features. Since I haven't been involved in C++ for a while, I am not currently in a position to push for a new version and I would prefer to allow other people to become a maintainer. What is the process to enable other maintainers to push the library forward? Best Matias

4 4

Review Wizard Status Report for May 2020
by Mateusz Loskot 20 May '20

20 May '20

============================================== Review Wizard Status Report for May 2020 ============================================== News ==== List of events that happened since the last report in 2016 is long and includes 13 releases of Boost, 21 libraries accepted and 4 libraries rejected. Details at https://www.boost.org/community/review_schedule.html What happened in 2020: 1. 2020-01: Ronald Garcia retired as a Review Wizard. Thank you Ronald! 2. 2020-02: StaticString accepted 3. 2020-04: Boost 1.73 Released New Libraries: - Nowide from Artyom Beilis, maintained by Alexander Grund - StaticString from Vinnie Falco and Krystian Stasiowski 4. 2020-05: Bimap library needs a maintainer https://lists.boost.org/Archives/boost/2020/05/248940.php Review Schedule Status ====================== The following libraries need a review manager: * JSON - author: Vinnie Falco, Krystian Stasiowski, Peter Dimov The following libraries have review managers, but have not yet been scheduled for review: * none The following libraries have review managers and have been scheduled for review: * LEAF - May 22, 2020 - May 31, 2020; author: Emil Dotchevski; review manager: Michael Caisse * Text - June 11, 2020 - June 20, 2020; author: Zach Laine; review manager: Glen Fernandes The following libraries have been reviewed and await reports from their review managers: * none The following libraries have been accepted to Boost, but have not yet been integrated into Boost Git: * Double-Ended - conditionally accepted in October 2017; author: Benedek Thaler * Parallel Sorting Sub-library - accepted November 2016; author: Francisco José Tapia The following libraries have been accepted and submitted to Boost Git, but have not yet appeared in a release: * STLInterfaces - conditionally accepted December 2019; author: Zach Laine The following libraries have been accepted provisionally to Boost, but have not been submitted for mini-review and full acceptance: * STLInterfaces - conditionally accepted December 2019; author: Zach Laine General Announcements ===================== As always, we need experienced review managers. Please take a look at the list of libraries in need of managers and check out their descriptions. In general review managers are active boost participants, including library contributors, infrastructure contributors, and other mailing list participants with a substantial track record of constructive participation. If you can serve as review manager for any of them, email us at Mateusz Loskot (mateusz at loskot dot net) or John Phillips (johnphillipsithaca at gmail dot com). We are also suffering from a lack of reviewers. While we all understand time pressures and the need to complete paying work, the strength of Boost is based on the detailed and informed reviews submitted by you. If you are interested in reviewing a library but won't have time during the review period, you can always prepare your review ahead of time. No rule says you can only work on a review during the review period. A link to this report will be posted to www.boost.org. If you would like us to make any modifications or additions to this report, please email Mateusz. The review schedule is an unordered list of the libraries awaiting review. As such, any library on the schedule can be reviewed once the developer is ready, a review manager has been secured, and the manager, developer, and wizards agree on a date to schedule the review. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

1 0

[interprocess] Mutex and condition at process termination
by Phil Endecott 20 May '20

20 May '20

Dear Experts, Can we improve how interprocess mutexes and condition variables behave on process termination? Currently if a process terminates (i.e. it crashes, or you press ctrl-C), the interprocess docs say nothing as far as I can see about what happens to locked mutexes and awaited conditions. In practice it seems that mutexes that were locked remain locked, and other processes will deadlock. (I'm using Linux.) A few thoughts: * If a process were only reading the shared state, then it would be appropriate for the mutex to be unlocked on termination. * If a process were modifying the shared state, then it would be wrong to unconditionally unlock the mutex. So it would be useful to distinguish between reader and writer locks, even if we're not implementing a single-writer/multiple-reader mutex. * The system could be made more robust by blocking signals while a mutex is locked. This doesn't help with crashes, e.g. segfaults, but it would help with ctrl-C. * It may be useful to cause all processes to terminate if one of them terminates with a mutex held for writing, either immediately or as soon as they try to lock the same mutex. Perhaps also to delete the presumed-corrupted shared memory segment. * PTHREAD_MUTEX_ROBUST might be part of the solution. That seems to require the non-crashed process to do clean up, i.e. we would need to record whether the crashed process were reading or writing and react appropriately. I'm less clear about what happens to condition variables, but it does seem that perhaps terminating a process while it is waiting on a condition will cause other processes to deadlock. Perhaps the wait conceptually returns and the mutex is re-locked during termination. I have encountered this while trying to use a simple diagnostic program that just dumps some shared memory data structures and waits on a condition in a loop. I run this for a while and then press ctrl-C. Yes, a while after I disconnect the diagnostic program the system crashes... the worst sort of bug! Regards, Phil.

6 17

Embarcadero PRs
by Edward Diener 20 May '20

20 May '20

I have PRs for these libraries, which have passed CI testing, for distinguishing the Embarcadero C++ clang-based compilers from the legacy bcc32 compiler: beast thread regex container python program_options units circular_buffer graph parameter unordered random typeof Can the maintainers of these libraries please merge the appropriate PR ? The PR should not affect any other compiler, and it gives a chance for the Embarcadero C++ clang-based compiler(s) to use the appropriate Boost library even when some lacking feature or Embarcadero bug currently prevents the full functionality of the library to be used.

1 0

Re: [boost] [B2] Propagate CXX requirements to consumers
by Nikita Kniazev 19 May '20

19 May '20

> I guess this could be solved if B2 allows negation. So I can say: > `<target-os>not windows:<build>no `. > Does this exist? It is supported, but was broken until recently https://github.com/boostorg/build/pull/594

1 0

BOOST_NO_CXX11_HDR_CHRONO?
by Frédéric 19 May '20

19 May '20

Hi, When I compile the following program: #include <boost/math/constants/constants.hpp> #include <chrono> int main() { return 0; } with a osx cross compiler based on clang 9 on linux,I get the following warnings (full output below): CAUTION: This message was generated due to the define: BOOST_NO_CXX11_HDR_CHRONO [-W#pragma-messages] This is quite strange as the compiler generates the binary which means there was no issue to find <chrono>. What's wrong then? Kind regards, F $ x86_64-apple-darwin13-clang++-libc++ -o boost_math_constants -Wall -Wextra -std=c++14 -m64 -mmacosx-version-min=10.9 -I/softs/osx64-clang-9.0.1/release/boost/include boost_math_constants.cpp In file included from Progs/boost_math_constants.cpp:1: In file included from /softs/osx64-clang-9.0.1/release/boost/include/boost/math/constants/constants.hpp:11: /softs/osx64-clang-9.0.1/release/boost/include/boost/math/tools/cxx03_warn.hpp:99:1: warning: CAUTION: One or more C++11 features were found to be unavailable [-W#pragma-messages] BOOST_PRAGMA_MESSAGE("CAUTION: One or more C++11 features were found to be unavailable") ^ /softs/osx64-clang-9.0.1/release/boost/include/boost/config/pragma_message.hpp:24:34: note: expanded from macro 'BOOST_PRAGMA_MESSAGE' # define BOOST_PRAGMA_MESSAGE(x) _Pragma(BOOST_STRINGIZE(message(x))) ^ <scratch space>:307:2: note: expanded from here message("CAUTION: One or more C++11 features were found to be unavailable") ^ In file included from Progs/boost_math_constants.cpp:1: In file included from /softs/osx64-clang-9.0.1/release/boost/include/boost/math/constants/constants.hpp:11: /softs/osx64-clang-9.0.1/release/boost/include/boost/math/tools/cxx03_warn.hpp:100:1: warning: CAUTION: Compiling Boost.Math in pre-C++11 conformance modes is now deprecated and will be removed from March 2021. [-W#pragma-messages] BOOST_PRAGMA_MESSAGE("CAUTION: Compiling Boost.Math in pre-C++11 conformance modes is now deprecated and will be removed from March 2021.") ^ /softs/osx64-clang-9.0.1/release/boost/include/boost/config/pragma_message.hpp:24:34: note: expanded from macro 'BOOST_PRAGMA_MESSAGE' # define BOOST_PRAGMA_MESSAGE(x) _Pragma(BOOST_STRINGIZE(message(x))) ^ <scratch space>:310:2: note: expanded from here message("CAUTION: Compiling Boost.Math in pre-C++11 conformance modes is now deprecated and will be removed from March 2021.") ^ In file included from Progs/boost_math_constants.cpp:1: In file included from /softs/osx64-clang-9.0.1/release/boost/include/boost/math/constants/constants.hpp:11: /softs/osx64-clang-9.0.1/release/boost/include/boost/math/tools/cxx03_warn.hpp:101:1: warning: CAUTION: Define BOOST_MATH_DISABLE_DEPRECATED_03_WARNING to suppress this message. [-W#pragma-messages] BOOST_PRAGMA_MESSAGE("CAUTION: Define BOOST_MATH_DISABLE_DEPRECATED_03_WARNING to suppress this message.") ^ /softs/osx64-clang-9.0.1/release/boost/include/boost/config/pragma_message.hpp:24:34: note: expanded from macro 'BOOST_PRAGMA_MESSAGE' # define BOOST_PRAGMA_MESSAGE(x) _Pragma(BOOST_STRINGIZE(message(x))) ^ <scratch space>:313:2: note: expanded from here message("CAUTION: Define BOOST_MATH_DISABLE_DEPRECATED_03_WARNING to suppress this message.") ^ In file included from Progs/boost_math_constants.cpp:1: In file included from /softs/osx64-clang-9.0.1/release/boost/include/boost/math/constants/constants.hpp:11: /softs/osx64-clang-9.0.1/release/boost/include/boost/math/tools/cxx03_warn.hpp:102:1: warning: CAUTION: This message was generated due to the define: BOOST_NO_CXX11_HDR_CHRONO [-W#pragma-messages] BOOST_PRAGMA_MESSAGE("CAUTION: This message was generated due to the define: " BOOST_MATH_CXX03_WARN_REASON) ^ /softs/osx64-clang-9.0.1/release/boost/include/boost/config/pragma_message.hpp:24:34: note: expanded from macro 'BOOST_PRAGMA_MESSAGE' # define BOOST_PRAGMA_MESSAGE(x) _Pragma(BOOST_STRINGIZE(message(x))) ^ <scratch space>:316:2: note: expanded from here message("CAUTION: This message was generated due to the define: " "BOOST_NO_CXX11_HDR_CHRONO") ^ 4 warnings generated.

5 15

[Config] Swappable/Movable std::streambuf requirement
by Alexander Grund 18 May '20

18 May '20

Hello, C++11 has `std::basic_streambuf<char>::swap` and move operators for that defined. However there are stdlibs which don't support that. clang 5.0 on travis e.g. fails due to that. Is there already something in Boost.Config dealing with that case which I can `requires` on to skip the build for that case? Most of the checks I've seen in Boost.Config are using the C++ feature test macros but for this there is none. If it doesn't exist: Would this be something to be added to Boost.Config? Or my local build files? How would such a test work? Can anyone point me to a similar example? I'm having trouble navigating over the many partially auto-generated files in Boost.Config. Thanks, Alex

2 2

Continued Fraction library/extension for Boost
by Fahad Syed 14 May '20

14 May '20

Hello, I am an Electrical Engineering fresher at National Institute of Technology, Srinagar. I have a proposal for a Continued Fraction class, with all arithmetic implemented through Gosper's HAKMEM algorithm. Here are some advantages/applications I can think of right now for a continued fraction representation: 1. Exact, base-independant representation of rationals AND irrationals (of course limited by the precision required) 2. Unlike rationals where numerator and denominator need to be "canonicalized" (i.e. divided by gcd for optimal representation), continued fraction arithmetic incorporates that naturally. 3. Approximation: Continued fraction give the best possible rational approximation for a given number 4. Comparison is extremely easy and fast 5. Conversion to float and base-conversion do not require division. Conversion to float, especially, is extremely fast and simple. I propose to implement most of the functions supported by the multi-precision library. Although I am sure there are many more applications and advantages, I would like some feedback on whether this library/extension would be of enough interest to be included in boost. Thank you.

1 0

[Filesystem] Directory entry caching
by Chris Glover 13 May '20

13 May '20

Hi All, Whatever happened to the work in this branch https://github.com/boostorg/filesystem/tree/feature/directory-entry-cache-r… that looks to implement this paper? http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0317r1.html Wondering if it's planned, dead, or looking for someone to do the work. I ran into the problem today by chance. -- chris

4 10

[Range] Transform in place
by Frederick Gotham 11 May '20

11 May '20

Earlier today I wrote the following two lines of code: auto const my_range = v | boost::adaptors::sliced(1,15) | boost::adaptors::strided(2); boost::range::transform( my_range, my_range.begin(), std::bit_not<uint8_t>() ); However it would have been nice as a one-liner: boost::range::transform( v | boost::adaptors::sliced(1,15) | boost::adaptors::strided(2), std::bit_not<uint8_t>() ); Why isn't there a form of "range::transform" that can transform in place (and therefore takes exactly two arguments)?

3 2