- Boost - lists.boost.org

[release] Boost 1.81.0 Beta 1 Release Candidate 1 is available
by Marshall Clow 13 Nov '22

13 Nov '22

Available at: <https://boostorg.jfrog.io/artifactory/main/beta/1.81.0.beta1/source/> The SHA256 checksums are as follows: 6b6b95fde0ec9c6c0e1584f35c6c2dc4eb6c8629c9635e844b8e6a9ad9594da1 boost_1_81_0_b1_rc1.tar.gz 9f2ce5d1cefb8f6b7e8cfcabc73632f348958e7cba2604dcb3688fecf6463d67 boost_1_81_0_b1_rc1.tar.bz2 e7547a789339499c6fc582a96ffb8989d97074f107520ddebc1ed5f30a0d6964 boost_1_81_0_b1_rc1.zip 758af4ae4f4224b6f2bd8f05fe0109d1f248c0377ee2dce03ccbeb30d82fb8b4 boost_1_81_0_b1_rc1.7z 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

8 10

ccmath::abs() gives wrong result
by Gero Peterhoff 11 Nov '22

11 Nov '22

Hi Matt, ccmath::abs() gives wrong result for FP-values std::numeric_limits<FP-Type>::min() in constexpr context. test case: using type = float; constexpr type a = std::numeric_limits<type>::min(), b = boost::math::ccmath::abs(a); std::cout << a << std::endl << b << std::endl; 1.17549e-38 nan The Problem is: template <typename T> inline constexpr T abs_impl(T x) noexcept { return boost::math::ccmath::isnan(x) ? std::numeric_limits<T>::quiet_NaN() : boost::math::ccmath::isinf(x) ? std::numeric_limits<T>::infinity() : x == -0 ? T(0) : x == (std::numeric_limits<T>::min)() ? std::numeric_limits<T>::quiet_NaN() : x > 0 ? x : -x; } In the case of FP-types, only the sign-bit has to be deleted, since one cannot assume that quiet_NaN() and/or signaling_NaN() are always unsigned. thx Gero

2 1

Boost 1.81.0 closed for major changes
by Glen Fernandes 09 Nov '22

09 Nov '22

Release has closed for major changes. Next week, 2022/11/09, master closes for all changes, in preparation for the beta. - Release team

3 3

Build Issue - URL - msvc-14.0
by Tom Kent 05 Nov '22

05 Nov '22

In preparation for the upcoming lockdown and release, I just grabbed the latest snapshot from here: https://boostorg.jfrog.io/artifactory/main/master/boost_1_81_0-snapshot.tar… I ran it through the build process and got some issues with boost::url running on msvc-14.0. Some examples of them are: D:\RB\boost_1_81_0\boost/url/param.hpp(886): error C2134: 'boost::urls::grammar::string_view_base::string_view_base': call does not result in a constant expression D:\RB\boost_1_81_0\boost/url/param.hpp(886): note: failure was caused by call of undefined function or one not declared 'constexpr' The full output log is here: https://gist.github.com/teeks99/8d14da5b50cffda13f9ad5e23a8d80aa Tom

3 4

Does ASIO really still uses reactor instead of proactor on some OSes or is documentation just outdated?
by Ivan Matek 29 Oct '22

29 Oct '22

If you go to https://www.boost.org/doc/libs/1_80_0/doc/html/boost_asio/overview/core/asy… you will see that it says: * On many platforms, Boost.Asio implements the Proactor design pattern in terms of a Reactor, such as select, epoll or kqueue. This implementation approach corresponds to the Proactor design pattern as follows: * *[...]* * On Windows NT, 2000 and XP, Boost.Asio takes advantage of overlapped I/O to provide an efficient implementation of the Proactor design pattern. This implementation approach corresponds to the Proactor design pattern as follows: * I am unfortunately not a pattern or OS expert, but I would expect that on every modern OS proactor can be implemented without using reactor, e.g. see *https://stackoverflow.com/a/57451551/700825 <https://stackoverflow.com/a/57451551/700825>* The fact that mentioned Windows are NT, XP and 2000 also furthers my suspicion that docs are outdated.

3 4

Boost.StaticString
by Vinnie Falco 29 Oct '22

29 Oct '22

Alan de Freitas has generously stepped up to maintain Boost.StaticString in the absence of Krystian. -- Regards, Vinnie Follow me on GitHub: https://github.com/vinniefalco

1 0

1.81.0 closed for new libraries and breaking changes
by Glen Fernandes 28 Oct '22

28 Oct '22

Next deadline: On 2022-11-02 Boost 1.81.0 closes for major code changes. Still open for serious problem fixes and docs changes without release manager review. - Boost release team

1 0

Wants to start contributing to boost libraries
by Shivam Rajput 28 Oct '22

28 Oct '22

Hey, I'm really interested to start contributing to boost, it would be really great if any of you could suggest which libraries that i can start with? Maybe any of the gsoc projects that need maintenance and more work? Currently I'm more interested in c++23 features and trying to implement some of them into libcxx. Thanks and regards Shivam

1 0

Reminder: Oct 26, 1.81.0 closed for new libraries and breaking changes
by Glen Fernandes 18 Oct '22

18 Oct '22

1.81.0 closes for new libraries and breaking changes next Wednesday (2022-10-26). We have two new accepted libraries: MySQL and URL, but only URL has been imported into the organization and has a submodule right now. Glen

3 2

New Library Proposal: xvec/simd
by Towner, Daniel 17 Oct '22

17 Oct '22

I would like to propose a SIMD/data-parallel header-only library for inclusion in boost. The library is an example implementation already developed by Intel of a C++ TS proposal called std::experimental::parallelism_v2::simd [1]. The library is styled as a data-parallel library where the programmer specifies the data parallelism available in the source program, and the compiler will generate the appropriate simd instruction sequences. The library is agnostic of simd element type and length, and within reason, should be able to target any processor with simd capabilities. Intel has added further generic extensions to the proposal, such as permutation operations and support for complex numbers [2]. Motivation: The concept of simd needs little introduction as the technique is widely used in high performance software and there are many libraries providing varying level of abstraction and portability. In [1], Matthias Kretz made a proposal to provide a standard C++ library which implements many data-parallel concepts in a portable, vendor-neutral style, and with tight integration with C++ (e.g., operator overloading, overloads for all appropriate standard library functions). That proposal and the feedback on it have been discussed in WG21 and Intel supports the proposal. There was an attempt to add a boost.simd library in the past but that was abandoned after its authors decided to commercialise it. Despite the availability of other simd or data-parallel libraries in the wider community there is still a gap for a data-parallel, width-agnostic, vendor neutral library with close integration into C++. The std::simd library proposal and its example implementation from Intel seem to fill this gap. The existence of an example implementation in boost will also make it easier to get users to adopt the TS and provide feedback to improve its API and feature set for real-world code. History: There are two strands of history that come together in this proposal: Intel's own vector libraries, and the C++ std::simd proposal. Intel has a long history of developing simd-capable processors and has its own libraries for accessing simd features [3]. A recent Intel project to refresh those libraries resulted in a new library called `xvec' which incorporates many modern C++ features and is deliberately vendor and target neutral, with the target being selected at compile-time. In 2013 the proposal was started, and then a C++ TS was published in 2018 [1] and discussed in WG21. Due to the similarities of the two libraries and their common goals, myself and Matthias Kretz are now working together on merging the simd specification from the Parallelism TS 2 into the IS for C++26. Status and Implementation: The `xvec' example library implemented by Intel supports most of the features of the std::simd proposal [1], along with a number of extensions to add some capabilities (e.g., generic permutation, complex number support) [2]. The library works in Linux and Windows, and can be compiled with GCC 12, LLVM 14 and Intel's oneAPI 2022. It is currently tested using googletest. Most of the library is implemented on top of the LLVM and GCC vector extensions [4], which makes it compilable on any target supported by those extensions. In a limited number of places intrinsics are used to access specific Intel instructions, but efficient generic fall-backs are also provided for simd targets which don't have those instructions (and this can included unsupported Intel processors too). Request: I would welcome any comments, questions or ideas on how to proceed with this proposal. [1] ISO/IEC TS 19570:2018, Programming Languages - Technical Specification for C++ Extensions for Parallelism, by Matthias Kretz. http://open-std.org/JTC1/SC22/WG21/docs/papers/2019/n4808.pdf [2] P2638R0: Intel's response to P1915R0 for std::simd parallelism in TS 2. https://wg21.link/p2638r0 [3] https://www.intel.com/content/www/us/en/develop/documentation/cpp-compiler-… [4] https://clang.llvm.org/docs/LanguageExtensions.html#vectors-and-extended-ve…

5 8