April 2025 - Boost - lists.boost.org

A proposal for a modern build-system
by Hassan Sajjad 08 Aug '25

08 Aug '25

Hi. I compiled 25 Boost libraries with C++20 header-units, including examples and Tests of a few. This resulted in a 1.44x speed-up if we exclude the scanning. Scanning was as slow as the header-unit build. I have a solution for that. I am sending this paper (Making some final edits) https://htmlpreview.github.io/?https://github.com/HassanSajjad-302/iso-pape… , which allows for a build-system to use a scanning-less approach to build header-units.This method requires only minimal modifications to the compiler and enables memory-mapped file sharing, which significantly reduces filesystem overhead and further boosts speed. My proposal for a scanning-less approach will allow HMake to have another amazing feature, monolithic Big header-units. BigHu will allow you to map all the headers from a directory to a single header-unit. This header-unit includes all these header-files and consumes them as header-files. Now, whenever the compiler requests a header-unit from this directory, the build-system instead sends this consolidated BigHu. This will not only improve the clean build speed, because of fewer process launches. But also massively boosts the rebuild speed as few header-units need to be read instead of lots of files. No source-code editing will be needed to use this feature. And you will have the option to either build a library as BigHu (if you don't mean to edit it) or as small header-units (if you are working on it). HMake will soon support compile_commands.json, which I guess can work fine with header-units. Thus you can benefit from both, faster compilation and working intelliscence. The API shown in hmake.cpp is a work in progress. HMake build-system benefits are numerous, even if we leave out the header-units support. This makes it a perfect replacement for B2. I believe we can complete the switch in the next 2 months. And if some compiler supports my paper, we get >3x faster compilation as well. Best, Hassan Sajjad

25 78

Adding optional<T&> find like method to associative containers in boost.
by Ivan Matek 18 Jul '25

18 Jul '25

Hi everybody, I presume somebody thought of this before but for some reason it never happened, but just in case it was never discussed I wonder if people here believe adding an nicer version of find(with different name obviously) to associative containers in boost would be beneficial? Since boost::optional allows references this would work. I presume naming is what most people will have strong feeling about. I personally prefer ofind/oat since I love short names, Barry suggested different names in his blog <https://brevzin.github.io/c++/2023/05/23/map-api/>, e.g. try_at. boost::optional did not get all the updates C++23 std::optional got, e.g. transform that make this usage compose nicely, but those could be added to boost::optional.

13 85

[review] [sqlite]
by Richard Hodges 29 Jun '25

29 Jun '25

Dear All, Surprise! The Boost formal review of the Boost SQLITE library starts *TODAY*, taking place from November 13th, 2024 to November 22nd, 2024 (inclusive). I apologise profusely for springing this on you without prior warning. The error is entirely mine. I am extending the period by one day to compensate. The library is authored by Klemens Morgenstern (@klemens-morgenstern in the CppLang slack). Documentation: https://klemens.dev/sqlite/ <https://anarthal.github.io/mysql/index.html> Source: https://github.com/klemens-morgenstern/sqlite <https://github.com/anarthal/mysql/> >From the documentation: boost.sqlite is a simple to use C++ sqlite library. It provides a modern interface using facilities like error_code, views (e.g. for blobs) and the ability to use boost.describe or boost.pfr for parameterised queries. Supported features include: - typed queries - prepared statements - json support - custom functions (scalar, aggregate, windows) - event hooks - virtual tables SQLite provides an excellent C-API, so this library does not attempt to hide, but to augment it. Please provide in your review information you think is valuable to explain your choice to ACCEPT or REJECT including SQLITE as a Boost library. Please be explicit about your decision (ACCEPT or REJECT). Some other questions you might want to consider answering: - Will the library bring additional out-of-the-box utility to Boost? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - Will the choice of API abstraction model ease the development of software that must talk to a SQLITE database? - Are there any immediate improvements that could be made after acceptance, if acceptance should happen? - 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 The review is open to anyone who is prepared to put in the work of evaluating and reviewing the library. Prior experience in contributing to Boost reviews is not a requirement. Thank you for your efforts in the Boost community. They are very much appreciated. Richard Hodges - review manager of the proposed Boost.SQLITE library Klemens is often available on CppLang Slack and of course by email should you require any clarification not covered by the documentation, as am I.

19 67

[OpenMethod] review starts on 28th of April
by Дмитрий Архипов 13 May '25

13 May '25

Dear Boost community. The peer review of the proposed Boost.OpenMethod will start on 28th of April and continue until May 7th. OpenMethods implements open methods in C++. Those are "virtual functions" defined outside of classes. They allow avoiding god classes, and visitors and provide a solution to the Expression Problem, and the banana-gorilla-jungle problem. They also support multiple dispatch. This library implements most of Stroustrup's multimethods proposal, with some new features, like customization points and inter-operability with smart pointers. And despite all that open-method calls are fast - on par with native virtual functions. You can find the source code of the library at https://github.com/jll63/Boost.OpenMethod/tree/master and read the documentation at https://jll63.github.io/Boost.OpenMethod/. The library is header-only and thus it is fairly easy to try it out. In addition, Christian Mazakas (of the C++ Alliance) has added the candidate library to his vcpkg repository (https://github.com/cmazakas/vcpkg-registry-test) The library is also available in Compiler Explorer under the name YOMM2. As the library is not domain-specific, everyone is very welcome to contribute a review either by sending it to the Boost mailing list, or me personally. In your review please state whether you recommend to reject or accept the library into Boost, and whether you suggest any conditions for acceptance. Other questions you might want to answer in your review are: * 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 what compiler? 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 problems tackled by the library? Thanks in advance for your time and effort! Dmitry Arkhipov, Staff Engineer at The C++ Alliance.

12 60

In 1.88.0, BCP creates project that doesn't build
by Mason Loyet 04 May '25

04 May '25

Hi, I am attempting to use BCP to put boost into a different namespace as below: mkdir myboost_1_88_0 curl -L https://archives.boost.io/release/1.88.0/source/boost_1_88_0.tar.bz2 | tar -xvjf - cd boost_1_88_0 && ./bootstrap.sh && ./b2 tools/bcp && ./dist/bin/bcp --namespace=myboost . ../myboost_1_88_0 cd ../myboost_1_88_0 ./b2 This results in: … error: Unable to find file or target named error: '/boost/align//boost_align' error: referred to from project at error: '/home/mloyet/external/boost-test/myboost_1_88_0/libs/atomic/build' The snippet appears to work for 1.84.0. Has something changed? Am I invoking BCP incorrectly? ________________________________ Note: This email is for the confidential use of the named addressee(s) only and may contain proprietary, confidential, or privileged information and/or personal data. If you are not the intended recipient, you are hereby notified that any review, dissemination, or copying of this email is strictly prohibited, and requested to notify the sender immediately and destroy this email and any attachments. Email transmission cannot be guaranteed to be secure or error-free. The Company, therefore, does not make any guarantees as to the completeness or accuracy of this email or any attachments. This email is for informational purposes only and does not constitute a recommendation, offer, request, or solicitation of any kind to buy, sell, subscribe, redeem, or perform any type of transaction of a financial product. Personal data, as defined by applicable data protection and privacy laws, contained in this email may be processed by the Company, and any of its affiliated or related companies, for legal, compliance, and/or business-related purposes. You may have rights regarding your personal data; for information on exercising these rights or the Company’s treatment of personal data, please email datarequests(a)jumptrading.com.

5 5

Library submission, checking out the interest
by Artem Shapovalov 04 May '25

04 May '25

Hello Boost dev community. Hope you are doing well and I'm doing right. I want to make my small contribution with my small library. It's a minimalistic implementation of a message bus that may connect together the pieces of code inside the same binary. Idea is: bring a microservices-like approach and the Publish-Subscribe pattern into a micro-level and allow all of the people not to reinvent the bicycle. Several times, I've re-implemented it because it's useful and had no reference implementation, and this is why I finally decided to make it, and I did. Here, you may check it out, it's generally satisfy some standards of Boost: https://github.com/Artem-Shapovalov/Independency Thanks for your attention. I hope you'll like it and find it useful and worth for Boost Libraries' family. Sincerely,Artem Shapovalov.

2 2

[OpenMethod] A pre-release feedback
by Andrzej Krzemienski 03 May '25

03 May '25

Hi Everyone, The library review starts still in two weeks, but I wanted to give some early feedback. First, I wanted to thank Jean-Louis for exploring the subject, writing and sharing the library, and for submitting it for the Boost Review. My feedback is based on the reading of the documentation, I haven't played with the library just yet. [1]. Animals as examples There are already a number of things in the library that suggest it might not be suitable for production use (I describe them below), but using class Animal as explanatory examples amplifies the impression that this is going to be a toy library. Half of the books I have read on OO use the Animal (or Employee) example, but never in my C++ career did I have to use OO to model something close to "animal". I know they are just examples, but picking one so detached from programming reality is in my estimation harmful. The arithmetic expression example is way better. I, for one, use OO for representing dynamically-configurable parts of the applications, such as plugins or user-selectable sorting or selection predicates. [2]. The motivation In C++ we already have a dynamic-dispatch tool for "closed set of methods with open set of types": virtual functions. We also have a dynamic-dispatch tool for "open set of methods with closed set of types": the visitation of std::variant. You need to provide a motivating example (more convincing than the zoo) that needs exactly this: "open set of methods with the open set of types". The arithmetic expression example doesn't do the job: there is a fixed and well known list of concrete types. Also, the fact that Bjarne Stroustrup wanted to add open methods long ago is insufficient a motivation. [3]. Are open methods compatible with static type checking? It looks that when one of the two things -- number of types, number of methods -- is known statically, the compiler can verify if the programmer didn't forget to take some type or method into account. (Well, sometimes we get the "pure virtual function call" error, but these are very rare cases.) The same seems not to be the case for open methods. What this library advertises as flexibility would be the source of many programmer bugs detected only at runtime, possibly by end users. Imagine that programmer Alice is adding her new type A and plugs it into open methods known to her, and at the same time programmer Bob in another file adds a new open method B known only to him. Bob doesn't know about class A, and Alice doesn't know about open method B. The ISO C++ proposals quoted in the docs mentioned solving this by a mandated or encouraged linker error. Is it possible for this library to diagnose the incomplete specification of an open method in the `initialize()` function? The docs use an expression, "when an error is encountered [...]". But note that in C++ we often use the term "error" to express the situation where a _correct_ program encounters a hostile situation in the environment (lack of resources, bad user input). But openmethod docs actually mean something different: a programmer bug. It is very easy for a programmer to plant a bug in this flexible design. [4] In a similar vein, the decision to select an arbitrary specialization of an open method upon a tie, is another runtime surprise: not even a reported error. For multi methods it is not even clear how a static check for exhaustive unambiguous specialization should work. [5] It is concerning that so many things are defined in the global namespace. The docs say, "First we need to include the library’s main header. It defines a few macros, and injects a name - virtual_ptr - in the global namespace." But then the reference part says that virtual_ptr is in the namespace boost::openmethod. Who is right? The fact that as common a name as `next` is reserved inside open methods is also uncomfortable. Why not use a namespace-scoped name? Next, the docs use the using-directive: `using namespace boost::openmethod;`. This is a bad idea: both for real programs and for the documentation: it is not clear if the library was designed with namespaces in mind. Also, all the examples define open methods in the global namespace. I instead would like the docs to show how to declare open methods in my namespace, as this is a far more probable use case. [6] Friendship It puzzles me how the notion of friendship can be combined with this idea of flexibility in open methods. It is my understanding that open methods are added on top of the existing classes. That is: classes do not have to know that some open method will be added in the future. In other words, open methods are non-intrusive, right? So how would a class know who to grant the friendship to? Also, the examples use the declaration `friend struct`, even though we are talking about methods. I think docs should mention the existence of these structs more prominently. [7] Function signatures Some macros in the library use function types in declarations: `BOOST_OPENMETHOD_OVERRIDERS(poke)<void(std::ostream&, virtual_ptr<Cat>)>` Others specify the type separately: `BOOST_OPENMETHOD_OVERRIDE(value, (virtual_ptr<Plus> node), int)` Is there a reason for this? Can the clever use of macros not offer the same function signature syntax? [8] Passing virtual pointers to const objects If `virtual_ptr<Cat>` is an analogue of this pointer, could we see an example in the docs that shows a virtual pointer to const objects? It would be `virtual_ptr<const Cat>`, I guess? [9] Is this library intended for production use? The library comes with a lot of clever macros, a lot of pointer type templates, a lot of new syntax and runtime surprises (mentioned earlier). I am concerned about how the debugging would look if something goes wrong with the usage of this library. Would you recommend it for use in production systems? Or is it for experimentation? [10] Minor things Section Custom RTTI has sentence: > Now we can include the "core" header and then header `boost/openmethod/core.hpp` is not included. Is it a bug? Regards, &rzej;

3 4

[OpenMethod] Questions about custom policies.
by Ivan Matek 01 May '25

01 May '25

Hello, I just started with review and I have a cluster of questions, but it is not clear what the root cause of my issues is so apologies if ordering of questions is wrong. 1. I wanted to get hash map stats, but they are not printed in debug policy, even when env variable is set, I must hack release policy like this: - vptr_vector<release>, vectored_error_handler<release>> {}; + vptr_vector<release>, vectored_error_handler<release>, basic_trace_output<release>> {} Is this expected? IDK why debug prints some trace, but not hash info 2. While playing with this I get crashes when I just c/p release policy and rename it, e.g. +struct my_release : basic_policy< + my_release, std_rtti, fast_perfect_hash<my_release>, + vptr_vector<my_release>, vectored_error_handler<my_release>> {}; crashes in template<bool Indirect> inline auto box_vptr(const vptr_type& vp) { if constexpr (Indirect) { return &vp; } else { return vp; } } but when I switch boost::openmethod::initialize<boost::openmethod::policies::my_release>(); to boost::openmethod::initialize<boost::openmethod::policies::release>(); it works fine. It also exibits some other weird behavior, e.g. if I switch debug inheritance from release to my_release crash goes away, even when not using debug... Looks to me I am doing something that is not allowed, but it is not clear what I am doing wrong. regards, Ivan

2 5

[OpenMethod] Some questions
by Andrzej Krzemienski 30 Apr '25

30 Apr '25

Hi Everyone, I have concerns with the design philosophy of OpenMethod library. Giving this flexibility that one person can add new open methods to a class hierarchy in one file and another person can add classes to a class hierarchy in another file independently, this is asking for miscommunication problems (programmer bugs) discovered only at runtime. I tried to recreate this situation that I expect would be common. My first question, even before I run tests is what will happen when I have a class hierarchy: struct Node { virtual ~Node(); }; struct XNode : Node {}; I declare an open method `value()` and override it for XNode in one file, adn in another file I extend the hierarchy with: struct YNode : Node {}; And then in main(), in yet another file, I will call `value()` with `YNode`. The documentation does not give me a clear answer. Section Error Handling says, > When an error is encountered, the program is terminated by a call to abort. And then in the next sentence it talks about different debug and release policies, and ultimately, I do not know if by default abort() is called or not. But that is not the only problem. The docs use the term " When an error is encountered". What is considered "an error" here? How many situations constitute "an error"? The docs should enumerate all these situations. I need to know when my program will be calling `abort()`. So, I dun a Compiler Explorer test: https://godbolt.org/z/3fW8j4eTM And indeed, I get something that looks like abort() But when I wrap the call into a try-catch block, all of a sudden, the implementation seems to pick the wrong overrider and return a value, clearly not the intended one. And the program goes on: https://godbolt.org/z/Y6z3o56h5 This is the worst thing that can happen: a random runtime behavior. Is this a bug? Or am I missing something? Next question that naturally arises: how do I declare `noexcept` open methods with this library? Regards, &rzej;

2 2

Proposal: Abandoning monolithic Boost documentation.
by René Ferdinand Rivera Morell 23 Apr '25

23 Apr '25

Today, in slack, we had a discussion on problems with building the monolithic docs. For context what I'm calling the monolithic docs are these <https://www.boost.org/doc/libs/1_88_0/doc/html/libraries.html>. The main problem that was raised is that a failure in one library causes all the docs to disappear. That problem is due to the nature of DocBook, XSLT, and the single monolithic generation. This is not something that can be resolved at the build system leve. The one solution is to abandon the monolithic build. And instead move to only having per library documentation builds. Hence.. I am proposing we abandon the monolithic documentation build. The benefits: * No longer missing docs from problems in individual libraries. * It's modular. I.e. libraries would build, and include, their docs in the modular layout. Do note that most libraries, more than 2/3, already use modular documentation. So technically this would be completing the modular transition that has already been happening. Thoughts? -- -- René Ferdinand Rivera Morell -- Don't Assume Anything -- No Supongas Nada -- Robot Dreams - http://robot-dreams.net

10 25

Review Manager Volunteers
by Matt Borland 23 Apr '25

23 Apr '25

Hi All, Recently, we've seen a shortage of review managers: Joaquin has been looking for one for his bloom-filters library for a few weeks (now solved), and Dmitry recently withdrew his GDB debugging tools due to lack of review manager. Looking at the review schedule for the last few years[1] you'll find a number of repeated names and long-time contributors. In an effort to find new volunteers for review managers I would like to ask what are the showstoppers that keep you from wanting to be a review manager? Time, Training, Recognition, none of the above? I am genuinely curious in an effort to find new volunteers so we can continue to add great libraries to the project. Thank you, and Happy Easter to those that celebrate. Matt [1] https://www.boost.org/community/review_schedule.html

12 25

Printf library suggestion
by Aaron Graham 23 Apr '25

23 Apr '25

I'd like to gauge the interest in adding the following library to boost: https://github.com/rokudev/rostd/blob/main/include/rostd/printx.hpp It's a simple library that checks and rewrites the format string at compile time in order to fortify it for use with printf, leaving the object code with only a call to the underlying C-standard printf-family function. It's a single header and requires C++20 or above (for cNTTP support). It contains these four functions: printf, sprintf, snprintf, fprintf These functions are used like so: printf<"Hello %s\n">("World!"); char buf[20]; sprintf<"Hello %s\n">(buf, "World!"); // yes, it's safe char buf[20]; snprintf<"Hello %s\n">(buf, sizeof buf, "World!"); fprintf<"Hello %s\n">(file, "World!"); Features/rationale: * It provides old-style printf (supports all standard printf specifiers). * Fully type-safe. No format string attacks. Issues are found at compile time. * Length modifiers are deduced; these format strings are portable. (No PRIu64 inttypes stuff needed anymore, just use %u) * Adds %? format specifier (print whatever type is there). * Compiles to std::printf (much smaller object code than std::format). * Provides a way for developers to easily adapt this printf formatting capability to their own functions (logging, etc.) More detailed rationale is here: https://github.com/rokudev/rostd/blob/main/doc/printx.adoc

2 1

Unable to migrate from Oracle Linux 8 to Oracle Linux 9 due to Boost dependency
by Pavithra Raghavendran 22 Apr '25

22 Apr '25

Hi Team We are writing this mail requesting your assistance for boost related issue which we are facing while migrating from Oracle Linux 8 (OL8) to Oracle Linux 9 (OL9) OS. Issue Description: When we try to upgrade the OS from OL8 to OL9, we are seeing errors related to boost version 1.66.0 and the RPM which was already successfully installed on OL8 is getting removed. Note: On OL8 OS, the available version of boost from yum is boost-1.66.0 & on OL9 OS, the available version of boost from yum is boost-1.75.0. Brief: Our application RPM is compiled on an OL8 machine(development machine) and is dependent on boost library (linked dynamically). When we install this RPM on another OL8 machine(test machine), the RPM installation is successful. This is because the boost version in our RPM and the test OL8 machine matches i.e. both require boost-1.66.0. However, when we upgrade the OS from OL8 to OL9, the application RPM is getting removed with the errors as shown below. This is because OL9 has boost-1.75.0 libraries but our RPM has boost libraries which is dynamically linked with boost-1.66.0. [root@vm227-66-vm5 ~]# dnf install ocsm-6.0.0.0.0-608.x86_64.rpm Last metadata expiration check: 0:13:25 ago on Tue 25 Mar 2025 12:25:18 PM CET. Error: Problem: conflicting requests - nothing provides libboost_filesystem.so.1.66.0()(64bit) needed by ocsm-6.0.0.0.0-608.x86_64 from @commandline - nothing provides libboost_program_options.so.1.66.0()(64bit) needed by ocsm-6.0.0.0.0-608.x86_64 from @commandline - nothing provides libboost_regex.so.1.66.0()(64bit) needed by ocsm-6.0.0.0.0-608.x86_64 from @commandline - nothing provides libboost_system.so.1.66.0()(64bit) needed by ocsm-6.0.0.0.0-608.x86_64 from @commandline Analysis: To simulate this above scenario, we have written a very simple sample program using the boost library and compiled the code on OL8 OS and linked dynamically with boost version 1.66.0. Once RPM is ready, we installed it on an OL8 virtual machine. Installation is successful because our compiled RPM has boost-1.66.0 libraries(libboost_program_options.so.1.66.0) and OL8 supported version of boost is also 1.66.0. Now, when we upgrade the OS from OL8 to OL9, the default boost available on OL9 is boost-1.75.0, and since our RPM is linked with boost-1.66.0 libraries, installation is failing with the below errors (similar to the application errors mentioned in Brief section). [root@localhost ~]# sudo dnf install boost_demo-1.0.0-1.el8.x86_64.rpm Last metadata expiration check: 0:23:05 ago on Mon 21 Apr 2025 01:00:57 PM CEST. Error: Problem: conflicting requests - nothing provides libboost_program_options.so.1.66.0()(64bit) needed by boost_demo-1.0.0-1.el8.x86_64 from @commandline - nothing provides libboost_system.so.1.66.0()(64bit) needed by boost_demo-1.0.0-1.el8.x86_64 from @commandlin In our application, we have not linked to any specific version of boost dependency i.e. we have nowhere mentioned the version of boost to be used as 1.66.0. Since OL8 yum repo has boost-1.66.0, our application is considering version 1.66.0 while building RPM. However, while migrating from OL8 to OL9 we are seeing the above-mentioned issue and hence we are unable to complete the upgradation process which is crucial to our customers. Query: Can you please let us know how we can ensure that the OS gets upgraded from OL8 to OL9, without application RPM(linked dynamically to boost-.1.66.0) being removed. Thanks Pavithra

2 1

[bloom] Review Announcement: Boost.Bloom (May 13-22, 2025)
by Arnaud Becheler 21 Apr '25

21 Apr '25

Dear Boost community, The review of the Boost.Bloom library begins on May 13th, 2025, and will run through May 22nd, 2025. Boost.Bloom is a header-only C++ library written by Joaquín M López Muñoz, providing fast and flexible Bloom filters. These are space-efficient probabilistic data structures used to test set membership with a controllable false positive rate and minimal memory footprint. The library supports a variety of configurations and hash policies and is designed to integrate well with modern C++. You can find the library here: - Repo: https://github.com/joaquintides/bloom - Documentation: https://master.bloom.cpp.al/ Bloom filters are especially useful when: - You need to test if something is not in a large dataset, and can tolerate a small false positive rate. (e.g., avoiding duplicate URL crawls in a web crawler) - You need a memory-efficient structure to represent large sets (e.g., checking for the presence of DNA subsequences across massive genomic datasets) - You want to avoid expensive lookups for items that are definitely not present (e.g., filtering nonexistent records before querying a remote database). As always, we welcome all reviews — from quick impressions to detailed analysis. Your feedback helps ensure that the library meets Boost's high standards in terms of correctness, performance, documentation, and design. If you’re interested in contributing a review, please post to the Boost mailing list during the review period. Note: All links to other parts of Boost in the Boost.Bloom documentation are currently broken, as they were written with the assumption that the library was already integrated into Boost - please do not account for those in your review. Thank you in advance for your time and insights! Best regards, Arnaud Becheler Review Manager, Boost.Bloom

2 1

Boost v1.88 Release Report
by Robert Beeston 18 Apr '25

18 Apr '25

The release report for v1.88 is now available, now packed with even more information including mailing list, slack, git commits and other statistical information that happened on the path to the current release. https://downloads.cppalliance.org/reports/boost_1_88_0_release_report.pdf *Rob Beeston* Creative Director C++ Alliance cppalliance.org

1 0

[bloom] Looking for a review manager for candidate Boost.Bloom
by Joaquin M López Muñoz 18 Apr '25

18 Apr '25

Candidate Boost.Bloom has been endorsed by members of the community, so I'd like to proceed with the official review and for that a volunteer is needed to act as the Review Manager: Repo: https://github.com/joaquintides/bloom Docs: https://master.bloom.cpp.al/ These are the general requisites and assigned tasks for the Review Manager: https://www.boost.org/community/reviews.html#Review_Manager If you're interested, please respond to this post and/or contact me privately. Thank you! Joaquin M Lopez Munoz

3 2

The state of modular Boost
by René Ferdinand Rivera Morell 16 Apr '25

16 Apr '25

Hello fellow developers, As you might remember many months ago I started asking library maintainers to merge the build (and sometimes source) changes needed to make it possible to consume Boost libraries in a modular way. At this point a good number of libraries have merged those PRs. And there have been a pair of Boost releases containing those changes. But there is still work to do. So far, we have: * 119 PRs merged so far! * 4 PRs needing work before they can be merged. * 1 PR that was merged to master but never merged to develop. * 45 PRs that can be merged immediately. What I'm asking now is for "forgiveness" as it were. The 45 PRs above are either PRs where the authors gave permission to the Boost github owners to review and merge. Or are for libraries that are effectively unmaintained (the authors did not respond to the PR or to the various requests for how to manage the changes, and haven't seen changes in them for some years). And the recent changes I made to the PRs was not with the build changes. But instead to fix the unmaintained CI of the libraries as they otherwise just did not work. What I want it for the github org owners to go ahead and merge these 45 PRs: https://github.com/users/grafikrobot/projects/1/views/7 Thank you. -- -- René Ferdinand Rivera Morell -- Don't Assume Anything -- No Supongas Nada -- Robot Dreams - http://robot-dreams.net

4 3

[OpenMethod] Boost.OpenMethod review scheduled
by Дмитрий Архипов 14 Apr '25

14 Apr '25

The review for the proposed Boost.OpenMethod library by Jean-Louis Leroy is scheduled to take place from April 28 to May 07. OpenMethods solve the Expression Problem by making it possible to define free virtual functions, i.e. virtual functions that exist outside of a class The library repository is here: https://github.com/jll63/Boost.OpenMethod. The documentation is here: https://jll63.github.io/Boost.OpenMethod.

3 3

Pretty printer module
by Дмитрий Архипов 14 Apr '25

14 Apr '25

Recently Niall Douglas posted about his idea to embed GDB pretty printers into binaries using a header. At the time I was thinking about a good way to deploy pretty printers for JSON that facilitates their autoloading. After Niall's post I experimented a little bit more, and I came to the conclusion that indeed nothing beats embedding via a C++ header in terms of convenience. At the same time I was also thinking about testing that pretty printers do in fact work. Given that pretty printers (usually) are implemented as a Python module, it initially looked like one could just run a Python program and import GDB Python modules. But actually you cannot. It turns out, though, you can run a Python script with GDB as the interpreter. After several iterations I arrived at this setup: https://github.com/boostorg/json/blob/develop/test/printers.cpp. A script converts this file into a Python script that uses GDB to break on certain lines and check if a particular expression produces a particular output when printed. While doing all this I thought that most of this work can be useful to other libraries. So, I moved the reusable parts into a separate directory (https://github.com/boostorg/json/tree/develop/pretty_printers) and added both a b2 module, and a CMake module. For B2. Importing: https://github.com/boostorg/json/blob/develop/build.jam#L8-L9 https://github.com/boostorg/json/blob/develop/build/Jamfile#L13 (Re)generating the header: https://github.com/boostorg/json/blob/develop/build/Jamfile#L88-L95 Testing: https://github.com/boostorg/json/blob/develop/test/Jamfile#L96-L101 For CMake: Importing: https://github.com/boostorg/json/blob/develop/CMakeLists.txt#L54-L55 (Re)generating the header: https://github.com/boostorg/json/blob/develop/CMakeLists.txt#L56-L63 Testing: https://github.com/boostorg/json/blob/develop/test/CMakeLists.txt#L80-L88 My questions to the community: do you find this useful? Would you use it in your Boost or non-Boost library? If you do, the module should be moved to tools rather than stay in libs/json.

12 26

[Release] The master branch is now open
by Marshall Clow 13 Apr '25

13 Apr '25

Thanks to everyone for their patience. The next release cycle will begin in late June. — The release managers.

1 0

boost::python and Python 3.12
by Tom Kacvinsky 13 Apr '25

13 Apr '25

While working on a project to upgrade an embedded Python interpreter (to Python 3.12), which uses boost::python, I noticed the structs from the Python C API now have more members and those extra struct members were not populated in the boost::python code. In particular I was bit by the enum module crashing our application startup. I noticed this with boost 1.78, but I found the same problematic code in the release that was current as of two months ago (1.87.0, I think). I got things to compile and run, but my approach was to just make the code Python 3.12 compliant. I can prepare a patch that has the appropriate macro guards for populating the structs as they relate to different Python versions. I'll read the boost developers guide and follow the necessary steps to submit a fix. Regards, Tom

2 2

[release] Boost 1.88.0
by Marshall Clow 13 Apr '25

13 Apr '25

Release 1.88.0 of the Boost C++ Libraries is now available. These open-source libraries work well with the C++ Standard Library, and are usable across a broad spectrum of applications. The Boost license encourages both commercial and non-commercial use. The release contains two new libraries: * Hash2: An extensible hashing framework, from Peter Dimov and Christian Mazakas. * MQTT5: MQTT5 client library built on top of Boost.Asio, from Ivica Siladić, Bruno Iljazović, and Korina Šimičević. as well as numerous enhancements and bug fixes for existing libraries. For details, including download links, see <http://www.boost.org/users/news/version_1.88.0> You can also download directly from: <https://archives.boost.io/release/1.88.0/source/> To install this release on your system, see <http://www.boost.org/doc/libs/release/more/getting_started/index.html> Thanks to everyone who participated in this release. -- The Boost Release Team Marshall Clow, Glen Fernandes, Ion Ion Gaztañaga

2 2

Git Debug Branch
by Robert Ramey 12 Apr '25

12 Apr '25

Sometime ago someone made the case that we should drop the Debug branch in the git storage for the libraries. I found the case pretty convincing and endorsed the change. However, it seems that the idea was not well received and the idea was not adopted. I hope my endorsement wasn't responsable for it's being dismissed. Now it seems that the idea HAS been adopted. I've found in both the libraries I maintain, some "maintainers" check into the master branch directly from a feature branch used for debugging. This was kind of problematic as the debug and master branch were no longer easily understood by doing a diff. Worse, other "maintainers" check into the debug branch in the traditional way leaving the merge to master as a separate operation in the traditional manner. My custom has been to merger to master just before the next release. I only dip into maintenance occasionally, so I don't remember all the details and I have to spend a lot of time looking at who did what. So, I'm announcing that I am unilaterally declaring soon I will be leaving the debug branch aside and not use it in the future. Those who have the authority to directly make changes in these libraries (as opposed do making a merge request) should know that any pushes to the debug branch will be lost. Robert Ramey

7 11

is it possible to run the tests on a different platform without the build-environment?
by Dennis Luehring 11 Apr '25

11 Apr '25

im building boost on a Win11 and run my boost-libs using application on an different/customized Win10 platform normally im running at least once the tests of the used libs when building boost cd boost-root\libs\asio\test b2 test the tests getting build and runned - nice and perfect but is there a way to run the builded tests on my other platform without installed development tools? its a very small reduced pseudo embedded Win 10 system

2 2

question re boost instalation
by Robert Ramey 11 Apr '25

11 Apr '25

I'm following the "getting started" part of the boost documentation. When I get to here - I get some message I don't understand. Anyone have any ideas? Robert Ramey $b2 install --prefix=bin/osx /Users/robertramey/WorkingProjects/modular-boost/tools/build/src/build/property.jam:363: in validate1 from module property error: Invalid property '<valgrind>on': unknown feature 'valgrind'. /Users/robertramey/WorkingProjects/modular-boost/tools/build/src/build/property.jam:372: in property.validate from module property /Users/robertramey/WorkingProjects/modular-boost/tools/build/src/tools/features/variant-feature.jam:102: in variant from module variant-feature libs/beast/Jamfile:44: in modules.load from module Jamfile</Users/robertramey/WorkingProjects/modular-boost/libs/beast> /Users/robertramey/WorkingProjects/modular-boost/tools/build/src/build/project.jam:544: in load-jamfile from module project /Users/robertramey/WorkingProjects/modular-boost/tools/build/src/build/project.jam:68: in project.load from module project Jamroot:450: in modules.load from module Jamfile</Users/robertramey/WorkingProjects/modular-boost> /Users/robertramey/WorkingProjects/modular-boost/tools/build/src/build/project.jam:544: in load-jamfile from module project /Users/robertramey/WorkingProjects/modular-boost/tools/build/src/build/project.jam:68: in load from module project /Users/robertramey/WorkingProjects/modular-boost/tools/build/src/build/project.jam:201: in project.find from module project /Users/robertramey/WorkingProjects/modular-boost/tools/build/src/build-system.jam:618: in module scope from module build-system $

2 1