June 2023 - Boost - lists.preview.boost.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

Library proposal - indexed_array
by Julien Blanc 12 Oct '23

12 Oct '23

Hi, I've written and released a (rather small) library which allows defining arrays with arbitrary index mechanisms (hence the name, indexed_array). This especially allows indexing with scoped enums, use non zero-starting indexes, or use sparse indexes. This is not a view, but an array in the sense that it owns the data, and provides the same guarantees and functionalities as std::array, such as triviality propagation, being able to reside in read-only program sections, etc. It also supports multidimensional indexing, and provides an indexed_span template class to access lower dimension content (which can be used outside indexed_array). Finally, it provides an opt-in safer way to initialize the array content, which is especially useful when using complex and/or changing indexing schemes (like based on externally generated files). The library is available here: https://github.com/Julien-Blanc-tgcm/indexed_array And the doc is here: https://julien-blanc-tgcm.github.io/indexed_array/ It requires C++17 and mp11, and has first-class support for describe-d enums. If there is some interest, i'd like to propose it for inclusion in boost. So i'm looking for people who would endorse it. Thanks and best regards, Julien

8 24

on windows flyweight simple_locking is using std::mutex but it should be using std::recursive_mutex()
by Foelsche, Peter 30 Jun '23

30 Jun '23

Dear All, On windows flyweight simple_locking is using std::mutex but it should be using std::recursive_mutex. I've got this firing an exception due to _Check_C_return() getting passed something else than success (number 3). I've checked by implementing my own locking policy and it definitely shows that the code is attempting to hold more than a single lock in parallel on the same mutex. The secured set.erase() can cause further flyweights to be destroyed given a suitable recursive use of flyweight. Kind Regards Peter Foelsche PS. Thanks for boost!

4 3

<stdfloat> support in Boost.Math
by Matt Borland 28 Jun '23

28 Jun '23

Today support was added for C++23’s <stdfloat> types in Boost.Math. Please let us know if you run into any warnings or errors as we go through the release captures, and betas in the following weeks. There are two common issues that we found. The first is a stack overflow in GCC 13.1 from their internal type promotion system. This will be fixed in 13.2, and we have added workarounds for it. The second are warnings and errors from implicit conversions between types. We have fixed hundreds of instances of these throughout the code base. Thank you for your help as always. Matt

1 0

Fernando Pelliccioni joins The C++ Alliance
by Vinnie Falco 28 Jun '23

28 Jun '23

I am pleased to announce that Fernando Pelliccioni has joined The C++ Alliance to become a full time contributor to Boost. This brings us to a total of 10 Staff Engineers working in C++, and 4 staff doing other work. -- Regards, Vinnie Follow me on GitHub: https://github.com/vinniefalco

1 0

Regarding the MySQL and Redis formal reviews
by Vinnie Falco 28 Jun '23

28 Jun '23

Dear All, This is a brief update on some pertinent developments. Foremost, I want to acknowledge the exceptional contributions of Ruben Perez, creator of Boost.MySQL, and Marcelo Silva, the author of Boost.Redis. Their hard work in developing and refining their respective Boost libraries exemplifies the best qualities of authorship. They are actively engaged in the various channels of the public C++ Slack Workspace (https://cppalliance.org/slack/) collaborating and answering questions. Consider joining. To clarify a potential misunderstanding, Ruben joined the C++ Alliance team only after his library Boost.MySQL was accepted. Therefore, his subsequent affiliation had no bearing on the outcome of the review. Regarding Marcelo, he has always worked independently on Boost.Redis and has no contractual relationship with The C++ Alliance. Next, I'd like to laud Klemens for his unwavering diligence. As the review manager for these two libraries, he operates with impartiality and independence from the C++ Alliance with no financial recompense. The C++ Alliance policies precludes any author sponsored by us from acting as a review manager for a library that we also sponsor. This policy underscores our belief and commitment to the effectiveness and integrity of the Boost Formal Review process. In conclusion, our objective has always remained consistent: to fortify and expand Boost, and to support the author and maintainer community. The talent, dedication, and hard work invested in making Boost the best it can be is truly commendable. Our motivation is driven by passion for the language and open source. Together, we can make Boost even more remarkable. Yours sincerely, Vinnie

1 0

Reminder: The deadline for "major changes" for Boost 1.83 is TOMORROW, 6/28
by Marshall Clow 28 Jun '23

28 Jun '23

As always, you can find the calendar at: https://www.boost.org/development/index.html — Your friendly release manager

1 0

Adding Search Functionality to boost.org
by Mohammad Nejati [ashtum] 27 Jun '23

27 Jun '23

Hey everyone, One of the issues with the current Boost website is the absence of search functionality. This forces users to rely on search engines and use queries like `site:boost.org asio cancellation_slot` However, this approach has several problems. Firstly, it often displays outdated versions in the search results. Secondly, it lacks a proper hierarchical presentation to effectively guide users. Moreover, there is no way to filter the results for a specific library. To address this problem quickly, we have decided to create a search index for the existing HTML documents on the Boost website. However, we encountered a primary challenge during this process. We needed to extract contents with the correct hierarchy for each library to ensure that the search results were displayed in a hierarchical manner. For instance, the results will be shown as `Asio › Reference › Deferred_values › Requirements` This hierarchical presentation can significantly enhance the user experience. The Boost libraries utilize various documentation formats such as QuickBook, AsciiDoc, Doxygen, and even multiple handwritten formats. This diversity posed a challenge in creating a generic crawler script. To overcome this obstacle, we initiated the Boost.Gecko project. This project involved the development of 16 custom crawlers, tailored to extract search records from the 151 Boost libraries. We are currently utilizing the Algolia search platform to index search records, which offers a free plan for open-source projects. Algolia also provides a rich JavaScript library for building a search interface on the frontend. We have leveraged this library to design a customized user interface for the search box, enhancing the navigation of search results. I kindly request you try out the new search functionality by visiting the demo page at: https://cppalliance.org/boost-gecko/ and share your thoughts, suggestions, or any issues you may encounter. Your input will greatly assist us in refining the search feature and ensuring it meets the needs of our users. Please note that the drop-down for selecting a library is included to simulate the experience of being on a specific library page. Our plan is to incorporate a search button into the header of every library page, defaulted to search within that specific library. Demo page: https://cppalliance.org/boost-gecko/ Repository: https://github.com/cppalliance/boost-gecko/ Respectfully Yours, Mohammad Nejati ---- C++ Alliance Staff Engineer

5 8

conversion of csv to pdf file
by Daggumati, Rajesh 26 Jun '23

26 Jun '23

Hi Team, As per project requirement, we need to convert .csv file to pdf file. Do we have any library to convert .csv file to pdf in boost Please let me know if we have any. Regards, Rajesh D 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

Adding 'indirect_sort' to boost::algorithm
by Marshall Clow 26 Jun '23

26 Jun '23

At Boostcon last month, there was a discussion of indirect sorting algorithms to boost::algorithm. An “Indirect sort” (called 'argsort' in numpy - https://numpy.org/doc/stable/reference/generated/numpy.argsort.html) returns a sequence of indices into the collection describing how the collection can be rearranged in order to become sorted. So I created https://github.com/boostorg/algorithm/pull/117 to start down this road. (There’s clearly more that could be done here - stable_sort, partial_sort, nth_element, etc) Comments welcomed. — Marshall

6 8

Boost.Pool regression: purge_memory() causes initial size to double on subsequent allocation
by Joel Hock 21 Jun '23

21 Jun '23

951ca5725 changed malloc_need_resize() to use set_next_size(), which sets start_size in addition to setting next_size. this causes repeated use of purge_memory() to allocate 2x size after every use. as illustration: >>>>>>>>>>>>>>>>> #include <boost/pool/pool.hpp> int main() { boost::pool pool(8); for(int i = 0; i < 10; i++) { printf("%d %ld\n", i, pool.get_next_size()); pool.purge_memory(); void *ptr = pool.malloc(); (void)ptr; } } <<<<<<<<<<<<<<<<< before the commit the output is: 0 32 1 64 2 64 3 64 4 64 5 64 6 64 7 64 8 64 9 64 after the commit, the output is: 0 32 1 64 2 128 3 256 4 512 5 1024 6 2048 7 4096 8 8192 9 16384

1 0

Boost Storytellers: Unordered
by Christian Mazakas 21 Jun '23

21 Jun '23

Hey everyone, I figured I'd take some time to talk about Unordered and where it's at. At the time of writing, Unordered's develop branch has been updated to include a new container: `boost::concurrent_flat_map`. A high-level description of the container and its algorithms can be found here: https://www.boost.org/doc/libs/develop/libs/unordered/doc/html/unordered.ht… It's been an honor and a privilege to develop alongside our own Joaquín M López Muñoz and Peter Dimov. While the advancements done to the algorithms themselves are note-worthy, what's not often talked about is taming implementation complexity. After all, algorithms don't mean much until they're translated to code. Boost.Unordered offers several different containers, all each a similar flavor of one another. The broad categorization is closed-addressing containerss, open-addressing containers and finally the concurrent containers, which are in actuality a subset of the open-addressing ones. The closed-adressing (CA) containers are the most straight-forward to abstract over as an `unordered_map` and `unordered_multimap` only differ in terms of how insertion is performed. Internally, the CA containers simply wrap a `table` struct that's templated over a Types policy-like which is used for pulling relevant typedefs from. Though I must confess, the `table` itself does contain myriad member functions such as `equals_unique` and `equal_equiv` which are used when comparing the tables themselves via `operator==`. The open-addressing (OA) containers are spiritually similar to the CA containers in that they wrap a simple common table type with a type policy template parameter used for pulling typedefs from in the relevant spots. But what makes the OA containers a good bit more nuanced is that there's both a `unordered_flat_map` and a `unordered_node_map`. The implementation complexity increases a good amount here. The CA containers all operate in terms of a simple `node`-like type that contains the appropriate `value_type` but the OA containers must abstract away a good bit more. The flat OA containers store their `value_type`s directly in a contiguous allocation so that lookup operations benefit from spatial locality in addition to being much more simple to manage from an implementation perspective. To support `unordered_node_map`, we have to update the type that's stored to be a `unique_ptr`-like. This essentially further extends the type policies already used by the containers to abstract over the storage type, the actual value type and how those values are accessed from a pointer to the storage type. This includes construction, destruction and dereferencing. The concurrent map adds yet another layer of abstraction but this time, in a much different spot and required a much larger holistic refactor of the codebase. The fundamental differences in container types require abstracting over how the table reads and inserts elements itself so we introduce an extra table layer. Previously there was but a single table type that supported all of the OA containers but now there's two table types that instead wrap a common `table_core` which contains common table primitives. The `concurrent_table` is responsible for managing its own locking schemes and then dispatches internally to its `table_core` and similarly for the `table` used by the non-concurrent containers. The OA containers are essentially implemented in 3 layers with the `table_core` being the lowest layer and the user-facing containers as the highest, with the specific middle layer being responsible for managing atomicity for the concurrent map and for providing things like iterators for the flat/node containers (the concurrent map offers no iterators). On paper it sounds relatively complex but in practice, navigating the code with this kind of foresight is easy and straight-forward, even more so now that GitHub's UI allows you to view and jump to struct definitions. Taming such implementation complexity into a neat and organized set of traits was definitely something beyond my skilset so I'm happy Joaquin was able to navigate such waters and I have a humbled understanding of policy-based design and how powerful it can be when applied properly. There's a couple of other things to note about the implementation that Boost authors may like. One is that we do allocator-aware constrution of a stack-local in emplace(). This is so that we can avoid a heap-allocation when doing lookup in the node-based OA containers. Originally, we actually didn't allocator-construct the stack-local but this turned out to be wholly incorrect because we'd move the stack-local to the heap when the key wasn't present in the container. This could lead to subtle bugs like not passing the memory resource when a user is using `std::pmr`. Another interesting aspect is that we recently updated the `erase(const_iterator)` method of the OA containers to return a proxy type. For performance reasons, the signature was originally `void erase(const_iterator)` but users found this cumbersome and annoying to work with as they'd often times swap containers entirely via a typedef. We now return a proxy type that lazily increments the internal iterator via implicit conversion to the container's iterator type. To this end, we're able to essentially have our cake and eat it too at the cost of making always-auto subtly confusing. I'm more than happy to talk about any other implementation strategies or answer questions if anyone is interested in the nitty gritty and can offer potential optimizations. - Christian

1 0

Re: [boost] charconv for C++11
by Gero Peterhoff 05 Jun '23

05 Jun '23

Hi Matt, thanks for your efforts. I have a few questions though: - Will charconv be included in boost 1.83 or which release is planned ? - Could you still include support for C++23 FP types (std::floatN_t) ? - Would it be possible to implement the FP functions constexpr ? thx & regards Gero

2 1

Windows Develop Regression Tests Failing - Boost Build?
by Tom Kent 04 Jun '23

04 Jun '23

When trying to run the regression tests for the develop branch from windows, I'm getting the following error: C:/teeks99-09/run/boost_bb/src/build\project.jam:284: in find-jamfile from module project error: Unable to load Jamfile. error: Could not find a Jamfile in directory '../../C:/teeks99-09/run/boost_root'. error: Attempted to find it with pattern '[Bb]uild.jam [Jj]amfile.v2 [Jj]amfile [Jj]amfile. [Jj]amfile.jam'. error: Please consult the documentation at 'https://www.bfgroup.xyz/b2/'. C:/teeks99-09/run/boost_bb/src/build\project.jam:347: in load-jamfile from module project C:/teeks99-09/run/boost_bb/src/build\project.jam:64: in load from module project C:/teeks99-09/run/boost_bb/src/build\project.jam:105: in load-used-projects from module project C:/teeks99-09/run/boost_bb/src/build\project.jam:75: in load from module project C:/teeks99-09/run/boost_bb/src/build\project.jam:134: in load-parent from module project C:/teeks99-09/run/boost_bb/src/build\project.jam:538: in initialize from module project C:/teeks99-09/run/boost_bb/src/build\project.jam:373: in load-jamfile from module project C:/teeks99-09/run/boost_bb/src/build\project.jam:64: in load from module project C:/teeks99-09/run/boost_bb/src/build\project.jam:167: in project.find from module project C:/teeks99-09/run/boost_bb/src\build-system.jam:618: in load from module build-system C:/teeks99-09/run/boost_bb/src/kernel\modules.jam:294: in import from module modules C:/teeks99-09/run/boost_bb/src/kernel/bootstrap.jam:135: in module scope from module It looks like the last good run I had was on march 11, which corresponds to the same day as this commit to that project.jam: https://github.com/boostorg/build/commit/fda357a8f55a08535afff0a11eec50fca1… That file doesn't mean much to me, is it possible it is causing the issue? Thanks, Tom

3 4

Moving sp_thread_pause, sp_thread_sleep to Core
by Christian Mazakas 02 Jun '23

02 Jun '23

Unordered's concurrent flat map contains a hand-rolled spinlock (graciously provided by Peter Dimov) but it contains a dependency on SmartPtr for the following two headers: #include <boost/smart_ptr/detail/sp_thread_pause.hpp> #include <boost/smart_ptr/detail/sp_thread_sleep.hpp> I advocate that we move these to Core. They're small, self-contained and are useful in broader contexts. Anyone have thoughts or objections? - Christian

5 14