October 2023 - Boost - lists.stage.boost.cppalliance.org

CMake Announcement from Boost Steering Committee
by Jon Kalb 13 Aug '24

13 Aug '24

The libraries produced by the Boost community have had a greater impact on the way that the C++ community writes code than any other library implementation. The focus of the Boost community will always be on the libraries, but it is undeniable that we are dependent on and often limited by the infrastructure of our trade. Years ago, the move to Git was contentious; yet, it was required to improve development. In a similar vein our build system has become an impediment for many developers and users, existing and prospective. Therefore, we, the Steering Committee, announce to the Boost community our desire and intent to move Boost’s build system to CMake for users and developers alike. We are soliciting comments and proposals from the community to guide the process and the goals. Our desire is that the community can come to consensus by the end of the calendar year with a vision of supporting users and developers. We understand that the actual process of achieving the end goal will be long, time consuming, and not without its share of conflict. We also recognize that the Boost community is comprised of bright and passionate individuals that are eager to get involved and help get work done. The members of the Steering Committee have been encouraged by the discussions and activity surrounding CMake on the mailing lists over the years and know that many people have voiced visions. We hope that each of you rejoins the discussion to support this initiative and contributes to the common goal of improving Boost’s integration into the broader C++ ecosystem. For the Boost Steering Committee, Jon Kalb, Chair jonkalb(a)boost.org

49 199

Boost Governance?
by René Ferdinand Rivera Morell 09 Aug '24

09 Aug '24

A disclaimer: I write this solely as a Boost Library author. And not in any other capacity or representing any other interest. It's now been at least a year since Boost switched from the Software Freedom Conservancy to the Boost Foundation for its governance organization. But have people noticed any difference? Did you know that switch happened? Did you know that they held an election for the Board of Directors and for the Officers? Do you know when that election happened? Do you know who got elected? Do you know how they were selected? Do you know what their responsibilities are? Do you know what their bylaws are? Do you know their financials? More importantly: Did you answer "no" to any of those questions? As a library author, I can say I definitely answered no to many of those questions. This is a problem. As authors, without asking, we should know those answers from the organization that governs our work. We should have input into how that organization governs. In other words, we deserve open and transparent governance; not the closed and opaque status quo. -- -- René Ferdinand Rivera Morell -- Don't Assume Anything -- No Supone Nada -- Robot Dreams - http://robot-dreams.net

10 9

Paul Bristow
by John Maddock 08 Aug '24

08 Aug '24

I've just heard that Paul Bristow who helped so much with the development of Boost.Math and indeed many other libraries, passed away peacefully last week. RIP Paul. Much missed. John.

6 5

boost::any_cast gives build errors with VS2022, boost v1.82 and C++17
by Bhuyan, Jyotideep 01 Jul '24

01 Jul '24

Hi, I was using VS2019, boost v1.78, and C++14 version and the below code was working well. Same code gives build error with VS2022, boost v1.82, and C++17 due to "o << *boost::any_cast<T>(&a); " Instruction. I wanted to know why it behaves differently. Code : class any_out { struct streamer { virtual void print(std::ostream& o, const boost::any& a) = 0; virtual streamer* clone() = 0; virtual ~streamer() {} }; public: any_out() : m_streamer(nullptr) { } ~any_out() { delete m_streamer; } template <typename T> any_out(const T& value) : m_streamer(new streamer_imp<T>), m_object(value) { } any_out(const any_out& a) : m_streamer(a.m_streamer ? a.m_streamer->clone() : nullptr), m_object(a.m_object) { } template <typename T> any_out& operator=(const T& r) { any_out(r).swap(*this); return *this; } any_out& operator=(const any_out& r) { any_out(r).swap(*this); return *this; } any_out& swap(any_out& r) noexcept { std::swap(m_streamer, r.m_streamer); std::swap(m_object, r.m_object); return *this; } friend std::ostream& operator<<(std::ostream& o, const any_out& a) { if(a.m_streamer) { a.m_streamer->print(o, a.m_object); } return o; } boost::any& get() { return m_object; } const boost::any get()const { return m_object; } bool empty() const { return m_object.empty(); } private: template <typename T> struct streamer_imp : public streamer { virtual void print(std::ostream& o, const boost::any& a) { try { if (a.empty()) { o << "<empty>"; } else { o << *boost::any_cast<T>(&a); } } } virtual streamer* clone() { return new streamer_imp<T>(); } }; // Members streamer* m_streamer; boost::any m_object; }; I have migrated to VS2022, boost v1.82, and C++17, and due to a build error, I have changed the code below. virtual void print(std::ostream& o, const boost::any& a) { try { if (a.empty()) { o << "<empty>"; } else { o << boost::any_cast<T*>(a); } } } any_out anyTest; anyTest = 100; std::string actualStr; actualStr = make_string() << anyTest; actualStr prints nullptr (0000000) instated of value 100 for VS2022, boost v1.82 and C++17 Best Regards, Jyotideep (JD) Please be advised that this email may contain confidential information. If you are not the intended recipient, please notify us by email by replying to the sender and delete this message. The sender disclaims that the content of this email constitutes an offer to enter into, or the acceptance of, any agreement; provided that the foregoing does not invalidate the binding effect of any digital or other electronic reproduction of a manual signature that is included in any attachment. Confidential - Company Proprietary

3 3

Linking Problems starting with Boost 1.81
by Dennis Luehring 05 Nov '23

05 Nov '23

1.79 links with my software 1.80 links with my software 1.81 does not link 1.82 does not link 1.83 does not link Linux up to date Suse/Tumbleweed gcc 13.2.1 ./bootstrap.sh ./b2 -j16 --toolset=gcc cxxflags=-fPIC --build-dir=./_build address-model=64 architecture=x86 threading=multi --stagedir=./lib64-gcc --build-type=complete --layout=versioned --without-mpi these are the errors on linking when using 1.81 and above ld.lld: error: duplicate symbol: boost::phoenix::placeholders::uarg1 >>> defined at local_256.hpp:16 (/home/linux/dev/3rdparty-linux-gcc/boost_1_83_0/boost/preprocessor/iteration/detail/limits/local_256.hpp:16) >>> Recipe_expression_validator.cpp.o:(boost::phoenix::placeholders::uarg1) in archive ../../implementation/expression_validation/libexpression_validation.a >>> defined at local_256.hpp:16 (/home/linux/dev/3rdparty-linux-gcc/boost_1_83_0/boost/preprocessor/iteration/detail/limits/local_256.hpp:16) >>> parser.cpp.o:(.bss+0xF80) in archive ../../devs/expression_parser_lib/libexpression_parser_lib.a ld.lld: error: duplicate symbol: boost::phoenix::placeholders::uarg2 >>> defined at local_256.hpp:19 (/home/linux/dev/3rdparty-linux-gcc/boost_1_83_0/boost/preprocessor/iteration/detail/limits/local_256.hpp:19) >>> Recipe_expression_validator.cpp.o:(boost::phoenix::placeholders::uarg2) in archive ../../implementation/expression_validation/libexpression_validation.a >>> defined at local_256.hpp:19 (/home/linux/dev/3rdparty-linux-gcc/boost_1_83_0/boost/preprocessor/iteration/detail/limits/local_256.hpp:19) >>> parser.cpp.o:(.bss+0xFC0) in archive ../../devs/expression_parser_lib/libexpression_parser_lib.a ld.lld: error: duplicate symbol: boost::phoenix::placeholders::uarg3 >>> defined at local_256.hpp:22 (/home/linux/dev/3rdparty-linux-gcc/boost_1_83_0/boost/preprocessor/iteration/detail/limits/local_256.hpp:22) >>> Recipe_expression_validator.cpp.o:(boost::phoenix::placeholders::uarg3) in archive ../../implementation/expression_validation/libexpression_validation.a >>> defined at local_256.hpp:22 (/home/linux/dev/3rdparty-linux-gcc/boost_1_83_0/boost/preprocessor/iteration/detail/limits/local_256.hpp:22) >>> parser.cpp.o:(.bss+0x1000) in archive ../../devs/expression_parser_lib/libexpression_parser_lib.a anyone got an idea what changed between 1.80 and 1.81 to let my linking fail with the above errors the expression_parser_lib and expression_validation is my own code

4 8

Reminder: Boost 1.84.0 release cycle starting
by Marshall Clow 04 Nov '23

04 Nov '23

The deadline for “major changes” is next Wednesday, 1-Nov. The beta release will be two weeks later. As always, the release calendar is at: https://www.boost.org/development/index.html — Marshall

5 5

[Release] Boost 1.84.0 closing for major changes TOMORROW
by Marshall Clow 31 Oct '23

31 Oct '23

Release closed for major code changes. Still open for serious problem fixes and docs changes without release manager review. See: https://www.boost.org/development/index.html — Marshall

1 0

[scope] Looking for endorsements and review manager
by Andrey Semashev 31 Oct '23

31 Oct '23

Hi, This is a reminder that Boost.Scope is looking for endorsements and a review manager. Following is an excerpt from the previous announcement, describing the library. Boost.Scope is a small library implementing utilities defined in <experimental/scope> from C++ Extensions for Library Fundamentals v3 with a few extensions. Namely, the library contains: * A number of scope guards for various use cases. * A unique resource wrapper that automatically frees the resource on destruction. * Utilities for wrapping POSIX-like file descriptors in the unique resource wrapper. Compared to <experimental/scope>, some notable extensions are: * A new scope_final scope guard, which is a more lightweight alternative to scope_exit. It is accompanied with the BOOST_SCOPE_FINAL macro that allows to simplify scope guard declaration syntax. * Scope guards can be activated/deactivated multiple times. * Scope guards can be created inactive initially. * Scope guard factory functions, for compatibility with C++11. * Support for optional resource traits in unique_resource wrapper, which improves usage with resources having unallocated values. * unique_resource supports swapping. * unique_resource supports dereferencing for any resource types that support dereferencing, not only pointers. * More flexible constructors for unique_resource. The library requires C++11 at the minimum and will significantly benefit from C++17. Source: https://github.com/Lastique/scope Docs: https://lastique.github.io/scope/libs/scope/doc/html/index.html The library is tested in CI and used in production in one of my projects. Thanks.

5 14

Use of boost::anys::unique_any in place of boost::any
by Bhuyan, Jyotideep 23 Oct '23

23 Oct '23

Hello, As per documentation, Boost::Any is getting deprecated, and it was suggested to use boost::anys::unique_any. I am using boost::any and boost::any_cast heavily in my application code. I am looking for some sample code for best practices on how we can replace boost::any and boost::any_cast with boost::anys::unique_any. I am using VS2022, boost v1.83, and building the code with C++17. Best Regards, Jyotideep Bhuyan (he/him) Please be advised that this email may contain confidential information. If you are not the intended recipient, please notify us by email by replying to the sender and delete this message. The sender disclaims that the content of this email constitutes an offer to enter into, or the acceptance of, any agreement; provided that the foregoing does not invalidate the binding effect of any digital or other electronic reproduction of a manual signature that is included in any attachment. Confidential - Company Proprietary

1 0

[Looking for Feedback] - Fairness lib
by Federico Abrignani 22 Oct '23

22 Oct '23

Dear Boost Community, I am writing to seek feedback on a new C++ library that I have been developing (https://github.com/Sernior/fairness <https://github.com/Sernior/fairness>). This library, named "*Fairness*," is still a work in progress. Nonetheless, I believe that this is an opportune time to begin gathering feedback. *Fairness* is designed to provide fair synchronization primitives. While the standard C++ library offers various tools for managing concurrency, it does not provide mechanisms for handling fairness policies. To introduce the most fundamental component of my library, the "priority_mutex," I would like to share a simple example: /#include <thread>/ /#include <chrono>/ /#include <algorithm>/ /#include <BS_thread_pool.hpp>/ /#include <boost/fairness.hpp>/ / / /static boost::fairness::priority_mutex<4> pm;/ / / /static void busy_wait_nano(int64_t nanoseconds){/ /auto begin = std::chrono::steady_clock::now();/ /for(;std::chrono::duration_cast<std::chrono::nanoseconds>(std::chrono::steady_clock::now() - begin).count() < nanoseconds;)/ / continue;/ /}/ / / /static void thread_function_nano(int p, int preCriticalTime, int postCriticalTime, int criticalTime){/ / busy_wait_nano(preCriticalTime);/ / pm.lock(p);/ / busy_wait_nano(criticalTime);/ / pm.unlock();/ / busy_wait_nano(postCriticalTime);/ /}/ / / /int main()/ /{/ / std::array<int, 8> prios {0, 2, 2, 1, 1, 3, 3, 0};/ / std::array<int, 8> preCT {2000, 1500, 2000, 3000, 1000, 500, 500, 2000};/ / std::array<int, 8> postCT {5000, 3000, 2000, 2500, 1000, 1500, 1500, 4500};/ / int criticalTime = 1000;/ / / / BS::thread_pool pool(8);/ / / / for (int i = 0; i < 8; ++i){/ / pool.push_task(thread_function_nano, prios[i], preCT[i], postCT[i], criticalTime);/ / }/ / pool.wait_for_tasks();/ / / / return 0;/ /} / /// using BS thread pool https://github.com/bshoshany/thread-pool in this example./ / / In this example priorities are not given randomly, you can see that I gave 0 priority (the highest priority) to thread 0 which has 2000 + 1000 + 5000 and thread 7 which has 2000 + 1000 + 4500. Priority mutexes function much like a `std::array`, using a 0-indexed based system. For instance, a `priority_mutex<4>` will manage priorities ranging from 0 to 3, with 0 being the highest priority. Currently, the library comprises priority mutexes, both recursive and shared versions, along with RAII wrappers such as `unique_lock` and `shared_lock`, all of which support priorities. There are, however, some elements still missing, including priority condvars and timed versions of the mutexes. The primary motivation behind creating this library is to enhance throughput in multi-threaded pipelines. To illustrate the concept more simply, imagine a pipeline with N tasks, some of which access a protected resource. In cases of contention, there exists an optimal order of resource accesses that minimizes overall execution time, https://sernior.github.io/fairness/ <https://sernior.github.io/fairness/> the images show 2 different ways of ordering critical sections one of which is much better than the other. This library aims to empower developers, who have profiled their software, to manipulate this order with minimal performance overhead and as simply as possible. In terms of implementation, much of the development has revolved around benchmarking and testing. During this process, I've experimented with over 10 different versions of the priority mutex. Ultimately, I achieved the best results by using a priority spinlock, which is also available to library users, to provide internal atomicity to the rest of the mutexes. An essential consideration in the implementation is ensuring that the internal priority spinlock is 128 bytes away from the rest of the memory used by the mutex especially the memory used to perform the atomic::wait on. This separation helps avoid false sharing. The choice of 128 bytes aligns with processor architectures like AMD Zen 4 (the one I am testing on), as indicated in their optimization manual. I can attest that without those 128 byte separation the PM_LockUnlock benchmark was 10X worse and the PM_pipeline_benchmark_fast was worse than the std counterpart (see below for the benchmarks). Another aspect to note in the implementation is the use of 4 bytes for booleans when only a single byte is needed. This decision is related to the way atomic::wait is implemented. Most standard library implementations of atomic::wait check if the type size is supported by the current platform's wait syscall. For instance, Windows can wait on 1 byte, while Linuxkernel based systems can only wait on 4 bytes. These are some benchmark results: 6.4.0-kali3-amd64 AMD Ryzen 5 7600X 6-Core Processor Now the LockUnlock benchmarks were the most difficult to optimize. Those are 8 threads simply doing: m.lock(); m.unlock(); The pipeline benchmarks (with different lenght) are actual pipelines where each thread has different times before/during/after the critical section and I try to set the priorities accordingly to finish as soon as possible. You can see there is also a mutex called slim_priority_mutex, that is a priority_mutex implementation that can support up to 7 (15 if boost atomic is found and your hardware supports the DWCAS) priorities. Those are light weight versions that only take 128 bits up to 7 priorities and past that, up to 15, 256 bits. I am also testing with a custom wait implementations (https://github.com/Sernior/fairness/blob/main/include/boost/fairness/detail… <https://github.com/Sernior/fairness/blob/main/include/boost/fairness/detail…>) which can be tested by defining BOOST_FAIRNESS_USE_EXPERIMENTAL_WAIT_NOTIFY. At some point I wish to make this wait the default version the lib uses instead of the std one since users of my lib could configure this version using my configs macros (number of fast spins - relaxed spins - yield spins before the wait syscall). As I said in the beginning other than to present my lib, this email has the purpose of obtaining feedback. I would like to see if there is anyone (other than me) interested in what I am doing and, if so, consider that I am still far from finished and I would love suggestions. Thank you all for your attention. Best regards, Federico Abrignani.

3 5