- Boost - lists.preview.boost.org

[bloom] Peer Review Conclusion
by Arnaud Becheler 01 Jun '25

01 Jun '25

Dear Boost Community, As Review Manager for Candidate Boost.Bloom, I have carefully reviewed and incorporated the community’s feedback from May 13–22 and hereby ACCEPT Boost.Bloom unconditionally. Congratulations to Joaquín on an outstanding contribution, and my genuine gratitude to everyone for their thorough analyses, respectful debates, and lively discussion. If I missed thanking anyone directly, please accept my apologies—your time and effort are greatly appreciated. The submission’s outstanding quality, the community engagement, the authors’ extensive experience with Boost and longstanding contributions, their responsiveness during the review process, and the fact that they’ve already begun integrating the proposed changes into the repository have convinced me to accept the library in its current form and trust that any further suggestions will be carefully considered. Consequently, I have not imposed any conditions on its acceptance. Finally, I’ll open a series of [peer-review]-tagged issues on the Boost.Bloom repository (https://github.com/joaquintides/bloom) to track each of these items for Joaquín. He’s already begun addressing many of them—so some may close immediately—but this will help us monitor progress. On a personal note, this was my first time serving in a Boost leadership role, and I found the experience both rewarding and constructive. My warmest thanks you all for making this experience positive and rewarding. --- ## Community recommendations I note that non-C++ Alliance reviewers rarely disclosed their affiliations. ### ACCEPT (7) 1. Claudio de Souza (May 18) (Undisclosed) 2. Ivan Matek (personal exchange: May 25) (Undisclosed) 3. Tomer Vromen (May 23) (Undisclosed) 4. Дмитрий Архипов (May 21) (C++ Alliance) 5. Christian Mazakas (May 21) (Undisclosed) 6. Vinnie Falco (May 22) (C++ Alliance) 7. Andrzej Krzemienski (May 22) (Undisclosed) ### ACCEPT CONDITIONALLY (1) 1. Kostas Savvidis (personal exchange: May 22) (Institute of Nuclear and Particle Physics Demokritos) ### NOT A REVIEW (5) 1. Peter Turcan (May 17) (C++ Alliance) 2. Ruben Perez (May 21) (C++ Alliance) 3. Seth (May 23) (Undisclosed) 4. David Bien (May 23) (Undisclosed) 5. Alexander Grund (May 23) (Undisclosed) --- ## Community feedback ### Mailing List 1. Strong consensus to accept - Nearly every reviewer recommends accepting Boost.Bloom, praising its code quality, interface, SIMD optimizations, and documentation. - It is my understanding it could become a "model" library for future contributions. 2. Documentation and onboarding - Add a friendlier getting-started section and introduction to Bloom filters - Add intuition behind mathematical equations - Clarify terms such as capacity vs. bit_capacity, may_contain, and fpr_for - Provide copy-and-paste-ready examples, syntax highlighting, and visuals for parameters vs. false-positive rate 3. Build and integration - Improve CMake support (generate Visual Studio solution, add gdb pretty-printers) - Document minimum C++ standard and supported compilers 4. API design and semantics - Reconsider or justify container-like features (emplace, allocator semantics) - Simplify template parameters or consider a hybrid compiled-lib approach - Ensure operator and method names are unambiguous and document preconditions 5. Performance and accuracy - Document real-world vs. theoretical false-positive rates - Provide post-construction FPR estimation utilities - Consider replacing custom RNG with a standard linear-congruential approach 6. Advanced features and suggestions - Add batch-lookup or multi-element tests - Highlight and document cache-line-blocked filters as a primary use-case - Offer utilities for computing memory requirements and alignment 7. Real-world integration - Include examples of Boost.Bloom in large projects (e.g., a bitcoind fork) 8. Minor refinements - Mention the origin of the Bloom filter name - Zero unused bits for deterministic serialization - Warn about potential OOM errors with unrealistic false-positive rates 9. Roadmap - Explore runtime-filter variation and Cuckoo/XOR filter support - Add bulk-lookup API - Formalize ContainerHash integration (e.g. `is_avalanching`) - Build examples/tests and coverage in CI to avoid code rot - Flesh out a guided tutorial narrative ### Slack The #boost channel on the Official C++ Language Slack Workspace (joinable at https://slack.cpp.al) was buzzing with animated discussions: - May 26: Joaquin and Sam Darwin about setting up code coverage for Boost.Bloom - May 25: Vinnie asked if a bitcoind fork using Boost.Bloom would be interesting, Joaquín agreed, and Janko pointed out Bitcoin already uses a rolling bloom filter. - May 22: Vinnie Falco asked Mohammed Nejati for a CMakeLists.txt to generate a VS solution for Boost.Bloom that lets you browse headers/sources, build and run tests, and debug with breakpoints: https://github.com/ashtum/bloom - May 21: Vinnie and all debugging why tests wouldn’t load—Janko suggested BUILD_TESTING, Vinnie tried it then learned there’s no CMake file in the test directory - May 21: Joaquín added CMake-based tests to Boost.Bloom and encountered a missing header error; Janko pointed out the tests needed to link against Boost::bloom, which fixed the build. - May 21: Pdimov clarified that listing individual Boost dependencies isn’t necessary when linking to Boost::bloom. - May 21: The channel then held an extended debate on whether Boost.Bloom’s interface should mimic standard containers, the role of allocators and template parameters, and the pros and cons of header-only versus compiled-library designs. - May 21: Vinnie called for volunteers to fork bitcoind to use Boost.Bloom, and later suggested extracting and summarizing the day’s discussion for the review records, add a link to the channel, and add a fancy ASCII banner to it (surely he was joking) _ join us at _(_)_ cpplang.slack.com#boost wWWWw _ @@@@ (_)@(_) vVVVv _ @@@@ (___) _(_)_ @@()@@ wWWWw (_)\ (___) _(_)_ @@()@@ Y (_)@(_) @@@@ (___) |/ Y (_)@(_) @@@@ \|/ (_)\ / Y \| \|/ /(_) \| |/ | \ | \ |/ | / \ | / \|/ |/ \| \|/ \\|// \\|/// \\\|// \\\|/// \|/// \\\|// \\|// \\\|// ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ### Reddit The full post lives here: https://www.reddit.com/r/cpp/comments/1klujy0/boostbloom_review_starts_on_m… - May 13, the author announced the Boost.Bloom library review, prompting 5 comments with questions and explanations. - One user asked if it was a container that “compresses” its contents - Another clarified that Bloom filters solve the set-membership problem by using a tunable bit array that guarantees no false negatives but allows configurable false-positive rates, ideal for fast, memory-efficient membership checks rather than full object storage. --- ## Conclusion Although I have tried my best to provide a thorough and accurate summary of the material, should any omissions, inaccuracies or plain mistakes remain, I respectfully ask for your understanding and welcome your corrections. Thank you for your time and consideration, Thank you Joaquín for this amazing library, and long live Boost.Bloom, Arnaud Becheler Boost.Bloom Review Manager

5 8

[openmethod] Peer review conclusion
by Дмитрий Архипов 28 May '25

28 May '25

Dear Boost community, the formal review of candidate Boost.OpenMethod has taken place between 28th of April and May 7th. I have received 6 reviews in total. Four of the reviews recommended unconditional, and 1 conditional acceptance. One reviewer recommended to reject the library. The reviews came from: - Joaquin M López Muñoz, - Christian Mazakas, - Ruben Perez, - Yannick Le Goc, - Klemens Morgenstern, - Andrzej Krzemienski. Also, several people have given insightful comments but did not provide a review. I would like to thank all of the people who took their time to write reviews or participate in the discussions. Your effort was very important and valuable. The outcome of the review is that Boost.OpenMethod is ACCEPTED with some CONDITIONS. 1. The convenience header <boost/openmethod.hpp> should be changed to not introduce identifiers to the global namespace. Reviewers suggested several alternatives to that: either moving those global entities into an alternative header, or put them into a dedicated namespace which users could use via using namespace. 2. The library should not choose an arbitrary ambiguous overrider. Virtually all reviewers have expressed strong dislike for this behaviour. The default should be an error. More lax overrider selection may be provided as an option. 3. The library's documentation should be improved in several areas: * The concepts used by the documentation should be explained early on and more thoroughly. * The library should not claim to implement N2216, as it diverges from it significantly. Instead it may remark on being inspired by it. * Better explain potential platform-specific limitations of certain use cases (runtime loading of shared libraries) and error conditions. In addition, I want to discuss several criticisms that have been expressed during the review. One is that essentially the library doesn't solve a problem that is worth solving. That is, you never need an open set of types combined with an open set of operations. I believe that 10 years of library's use should mostly dispel such concerns. I personally have also encountered such a situation in my practice. The second criticism is that the flexibility of the library comes with higher chance of programmer error, as some usual safe guards go out the window. I can attest that in "many types, many operations" situations alternative approaches are comparably error-prone. It seems to me that this is largely inherent to the complexity of the problem. My advice to the author is to highlight dangerous situations, so that potential users can better evaluate if the added flexibility is worth it. Thanks to Jean-Louis Leroy for submitting this library to Boost. And thanks again to the reviewers and everyone who provided feedback, who ultimately made this review possible.

2 1

Boost.MSM docs
by Vinícius dos Santos Oliveira 28 May '25

28 May '25

Where are they? They've gone. I only see 404 when I try to access its docs. -- Vinícius dos Santos Oliveira https://vinipsmaker.github.io/

3 2

[openmethod] Joaquin's syntax suggestion
by Jean-Louis Leroy 25 May '25

25 May '25

During the review, Joaquin suggested changing the syntax for declaring and overriding methods, from: BOOST_OPENMETHOD(poke, (virtual_ptr<Animal>, std::ostream&), void); BOOST_OPENMETHOD_OVERRIDE( poke, (virtual_ptr<Bulldog> dog, std::ostream& os), void) { ... } to: BOOST_OPENMETHOD(poke, void(virtual_ptr<Animal>, std::ostream&)); BOOST_OPENMETHOD_OVERRIDE( poke, void(virtual_ptr<Bulldog> dog, std::ostream& os)) { ... } The difficulty with this is that the macros generate several constructs using the method name, formal parameter list and return type. Steven suggested a trick to implement a similar syntax, using trailing return types: BOOST_OPENMETHOD(poke, (virtual_ptr<Animal>, std::ostream&)->void); BOOST_OPENMETHOD_OVERRIDE( poke, (virtual_ptr<Bulldog> dog, std::ostream& os)->void) { ... } but I am not 100% sure if he actually _supports_ the change. @Steven, do you? Personally, I like the above because it simplifies the macros. But it has a couple of drawbacks. 1. `(virtual_ptr<Animal>, std::ostream&)->void` is not legal C++, `auto (virtual_ptr<Animal>, std::ostream&)->void` is. Isn't this going to cause confusion? 2. Count on MSVC to spoil things. If the return type is explicitly derived from a template, MSVC errors on it. Here is a reduction: #include <string> #include <tuple> template<typename> struct test{}; using foo = test<auto (int)->std::string>; using bar = test<auto (int)->std::tuple<int>>; // MSVC fails on this using baz = test<auto (int)->decltype(std::tuple<int>())>; // workaround Compiler Explorer: https://godbolt.org/z/MrbdYbW9Y It looks like a parser bug, I reported it. To all those who did _not_ suggest this change, if you oppose it, please let me know. J-L

2 3

[Bloom] review starts on 13th of May
by Arnaud Becheler 23 May '25

23 May '25

Dear Boost community, The review of the Boost.Bloom library begins today 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. 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? 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

14 35

[bloom] Andrzej's feedback
by Andrzej Krzemienski 22 May '25

22 May '25

Hi Everyone, The following can hardly be called a library review, but I still wanted to give this feedback. The documentation of this library meets what I call the highest standards of Boost. What attracted me to Boost originally was the way the libraries were documented. Studying each new library was learning something new: about programming, about structuring your program, about structuring your thoughts. A lot of libraries, back then, first documented the problem domain, then gave you some theory behind it, then listed possible approaches, and then finally also presented to you the chosen solution. Boost.Bloom represents the same character. I did not know what Bloom Filters were before reading the docs. Now I feel I do. I learned about the problem domain. I was convinced that the problem domain is worth addressing. I know the technical challenges. I know what to expect of the library interface (without having looked at the reference section)! I can already answer one of the review questions. Is the design of the library sound? If the author was able to explain the problem domain and the technical challenges/trade-offs so clearly and succinctly, then I am confident that the library design must be sound. Some interface suggestions: 1. Use the term "bit_capacity" rather than "capacity" for representing capacity in bits. This is not to accidently mislead the users. 2. It is a good move to use the name "may_contain" rather than "contains", but "may_contain" actually also doesn't do justice to the semantics either. The user is asking, "do you contain the value", and the library is replying, "maybe I do, and maybe I don't". Actually, I am unable to suggest anything better. If the function name was `f.definately_misses()` then a true/false answer would be meaningful. and the opposite of "definately_misses" is "either 'contains', or 'misses' incorrectly classified as 'contains'". But I realize that it is longer and contains negatives. So I think your choice of the name is the best given the set of alternatives. 3. When describing the |= operator, use the name "set union", which is the industry standard. The current choice of words "containing both the elements of f and f2" can be interpreted both as a union and as an intersection. 4. I am uneasy about the functionality under &= operator. It implies symmetry with operator |=. But the symmetry is broken for at least two reasons: * If I put some elements to filter f1 and some other elements to filter f2, and then I apply |=, then the effect is the same as if I put all the elements in f1 to begin with. The same property, if I understand correctly, does not apply to operator &=. * The compromising of the FPR value that you are describing. I am not sure if anyone ever needs this intersection behavior. But if it is useful, maybe reflect this lack of symmetry by using a named function rather than an operator? 5. Does the suffix "_for" in the name "fpr_for" bring any value? 6. Not sure if it is a good idea to have two overloads for `reset()` doing slightly different things. For constructors this is unavoidable, but for member functions, you can have `reset` and `reset_for`. 7. I think that you are missing a precondition for operators &= and |=. They work under the assumptions that for both filters f1 and f2 inserting the same element renders the same bit pattern in the hash. But this is not the case when the hashers that I provide to f1 and f2 have the same type but different initial state: filter<T, MyHash> f1(1000, MyHash{1}); filter<T, MyHash> f2(1000, MyHash{2}); The above feedback is based on me having read the documentation. I haven't tried the library, and it is unlikely that I will be able to do this within the review period, so I am not sure if I am qualified to give a recommendation for accepting the library into Boost. Joaquín, thank you for writing and sharing this library! Regards, &rzej;

3 9

Website update
by Robert Beeston 21 May '25

21 May '25

Thanks to everyone who pointed out issues and improvements following the new website launch! We appreciate the feedback, and are working on improvements and remediation. Some of the updates so far include: - Fixed issues with the charconv documentation on both the master and develop branches. - Cleaned up some doc formatting and squashed a bug in the library import logic. - Made sure certain libraries don't get wrapped in a layout they shouldn't be using. - Tweaked the rendering so the docs look more like the original Boost site, closer to what users expect. - Updated the featured video on the homepage to keep things fresh. - Added IPv6 (dualstack) support for AWS S3, improving compatibility and future-proofing. - Swapped out some banner images to keep the look up-to-date. - Fixed links to stl.boost.org We still have plenty to do, and we'll report back when there is more to share. Don't be surprised if you catch the improvements before they are announced. If you do see anything else that needs to be addressed, please feel free to respond here or add a ticket to the repo <https://github.com/boostorg/website-v2/issues/new/choose> Thanks again for your continued patience and support! *Rob Beeston* Creative Director C++ Alliance cppalliance.org

2 1

[Bloom] Some questions
by Ivan Matek 21 May '25

21 May '25

Hi everybody, I was reading the documentation/code, and I have some questions/comments. 1. Why is unit of measurement bit? I understand that conceptually bloom filters(maybe others, did not check) are bit arrays, but for me this seems like very error prone. Would verbose alternative of using boost::bloom::bits(1000) or boost::bloom::bytes(125) be preferred? I did not suggest UDL, as I feel for such rarely used class it may be overkill. 2. boost::hash<short> (and other integral ones) afaik are identity, I presume this is not an issue because you do extra steps if hash_is_avalanching is false, but maybe users should prefer avalanching hash? If so maybe suggest fast avalanching hash available in boost... btw I tried to read the docs but I got(not a big issue, since I read them from original. version): 404 Not Found - Code: NoSuchKey - Message: The specified key does not exist. - Key: develop.bloom.cpp.al/unordered/doc/html/unordered/reference/hash_traits.html - RequestId: JHRNESDX8BYY6T2G - HostId: nz9kkYamNQ4ocu023JneA7PyMHTEyQK9jgMSSBuwReE0OQAslcN0xOZxgopXpvn/63AFQzreXgM= 3. libs/unordered/include/boost/unordered/detail/mulx.hpp contains mulx implementation that seems very similar to one used in bloom, and authors are same. Although this is tiny duplication, would it be best to extract it somewhere to avoid duplication? 4. Is there no benefit in having a power of 2 sized bloom filters? AFAIK it is trick used by hash maps (requires hash is good) to get faster indexing. I see you use clever 128bit multiplication that generates fast mul instruction to avoid division, but I still presume shift and masking would be faster. 5. Why is BOOST_ASSERT(fpr>=0.0&&fpr<=1.0); not BOOST_ASSERT(fpr>0.0&&fpr<=1.0); , i.e. is there benefit of allowing calls with impossible fpr argument? This may sound like nitpicking, but I think it is wrong to allow calls with arguments that give people wrong idea of what bloom filters are capable. I understand that this functionality is under capacity *esimation**,*but I still think it may be confusing. 6. Related to 6. : It is relatively easy to OOM with this if you are "reckless" with fpr value, I would add a suggestion to docs to mention this(if it is not already there, maybe I missed it). 7. It may be just me, but I believe Filter Definition chapter would benefit from visual example, in particular how is BucketSize related to subarray size. 8. Regarding choosing optimal value: In the example we use 10M elements. From what I see they are unused in our computations till the end so I would rewrite: "*Suppose we plan to insert 10M elements and want to keep the FPR at 10−4. The chart gives us five possibilities:*" to something like " Suppose we plan to insert 10M elements and want to keep the FPR at 10−4. Looking up FPR in the chart(this step is not dependent on number of elements) gives us five possibilities:" 9. My IDE complains about redundant inline on member functions. Is this intentionally done since (afaik msvc) some compilers use inline as optimization(inlining) hint or? 10. Should #if 1 in may_contain be there?

5 21

[Bloom] Submit Your Review – Only Two Days Left!
by Arnaud Becheler 20 May '25

20 May '25

Dear Boost community, As a reminder, the review period for the candidate Boost.Bloom library by Joaquín M López Muñoz is set to close in two days, on May 22nd, 2025. If you haven’t had a chance to submit your review yet, there’s still time! All feedback is welcome—whether it’s a quick first impression or a detailed analysis, every comment helps us maintain the quality and standards of Boost libraries. You can find the library here: - Repo: https://github.com/joaquintides/bloom - Documentation: https://master.bloom.cpp.al/ Courtesy from Christian Mazakas, you may want to try out their Boost Nightly demo repository during the Boost.Bloom review period: https://github.com/cmazakas/vcpkg-registry-test If you’re interested in participating but need a bit more time, please let me know—it may be possible to extend the review window slightly to accommodate additional feedback. Thank you to everyone who has already contributed! Best regards, Arnaud Becheler Review Manager, Boost.Bloom

1 0

[openmethod] [policies]
by Jean-Louis Leroy 20 May '25

20 May '25

Hi all, and in particular Joaquín, Christian, Ruben and Steven who contributed remarks on the policy system. I followed some of Ruben's suggestions. There is now a registry that contains collections of classes and methods, and, after initialize(), dispatch data. It also contains a collection of policies. In part this is "just" renaming: what used to be a Policy is now a Registry, and what used to be a Facet is now a Policy. But this is not just cosmetic. The registry mechanism is clearly separated from the policies. Many old facets were CRTP templates, but not always. Now a policy (ex-facet) is - always - a Mp11 quoted meta-function that takes a registry as a single argument. This complicates creating policies a bit, but makes using them much easier, I think. CRTP is gone from the interface (in fact it is hidden). `fork` is gone. The debug and release stock policies looked like this: struct release : basic_policy< release, std_rtti, fast_perfect_hash<release>, vptr_vector<release>, vectored_error_handler<release>> {}; struct debug : release::fork<debug>::with< runtime_checks, basic_error_output<debug>, basic_trace_output<debug>> {}; Now they are: struct release : registry< std_rtti, fast_perfect_hash, vptr_vector, vectored_error_handler, stderr_output> {}; struct debug : registry< std_rtti, fast_perfect_hash, vptr_vector, vectored_error_handler, stderr_output, runtime_checks, trace> {}; An application that wants to use a standard map instead of a fast hash table, and keep all the rest the same, could say: struct my_registry : default_registry::with<vptr_map<>> {}; Or, using an unordered_flat_map: struct my_registry : default_registry::with< vptr_map<boost::mp11::mp_quote<boost::unordered_flat_map>>> {}; I also took Ruben's suggestion of having only one output policy, instead of one for error reporting, and one for tracing. Now, even in release builds, the default handler writes a diagnostic to stderr, before calling abort(). Policies are not aggregated via multiple inheritance anymore. At the moment, I am not convinced with Ruben's approach of making the registry (formerly policy) an object. There would still need to be a static instance of that object, which would contain instances of policy objects. Six of one or half of a dozen of the other. From there Ruben suggested making the dependencies between policies (ex-facets) explicit, as far as I can see this leads to a mess of conditionally enabled constructors. You can see the changes here: https://github.com/jll63/Boost.OpenMethod/pull/22 It's still a draft. The documentation is not yet updated, I'll do a big doc pass when things stabilize again. If you want to post comments directly to the PRs, drop me a line and I will invite you as a collaborator. J-L

2 2

Fwd: [Boost-docs] SGI STL Documentation gone from Boost website ?
by René Ferdinand Rivera Morell 19 May '25

19 May '25

---------- Forwarded message --------- From: Adder via Boost-docs <boost-docs(a)lists.boost.org> Date: Mon, May 19, 2025 at 5:31 PM Subject: [Boost-docs] SGI STL Documentation gone from Boost website ? To: <Boost-docs(a)lists.boost.org> Cc: Adder <adder.thief(a)gmail.com> Dear Authors of Boost and Maintainers of the Boost website, I used to find it useful to find the original STL Documentation on the Boost website, but now https://www.boost.org/sgi/stl/ now gives "404 - Page Not Found". May I ask whether this is intentional or just an accident, please ? Anyway, many thanks for everything you have been doing !! >:D< Adder _______________________________________________ Boost-docs mailing list Boost-docs(a)lists.boost.org https://lists.boost.org/mailman/listinfo.cgi/boost-docs -- -- René Ferdinand Rivera Morell -- Don't Assume Anything -- No Supongas Nada -- Robot Dreams - http://robot-dreams.net

2 1

[review] boost.bloom
by Claudio DeSouza 18 May '25

18 May '25

Hello there, I have spent some time playing around with boost.bloom and my review is ACCEPT. The library is very well written, provides intuitive interfaces that are already common in C++ and familiar to users, and the SIMD optimisations are very impressive. Documentation is exemplary, although I would suggest adding a short summary of how this is not a container despite the similarities in interface but how in practice it differs from a set, so the short of attention can better catch the gist of it. I feel the source code could have been better documented for future maintainers, but that’s of no importance overall. I looked into other implementations for bloom filters, and this boost implementation could be described as “very fancy”, however the user experience has no unnecessary clutter and is friendly enough to the non-expert. I particularly must admit I felt out of depth opining in the implementation in general beyond recognising this candidate stands out in its quality by comparison with other implementations. Bloom looks exactly like the sort of thing boost is known to provide model implementation for, and it seems to be a perfect candidate to boost. A sort of “going back to its roots” IMO. Claudio

2 1

[fsc] New website is up at boost.org
by Joaquin M López Muñoz 13 May '25

13 May '25

As all of you have probably already found out by now, boost.org <http://boost.org> is now hosting the long anticipated new website! This has been a lot of work by a lot of people, and we at the FSC are so happy that the project has finally seen the light and would like to say big thanks to everybody involved. The new website is probably the most visible result of the new Fiscal Sponsorship Model approved by the community in September 2024. Please take a moment to review the site and provide your feedback, either here or by filling an issue at https://github.com/boostorg/website-v2/issues <https://github.com/boostorg/website-v2/issues> Looking forward to upcoming developments in the Boost Project. Joaquin M Lopez Munoz Boost Fiscal Sponsorship Committee

7 9

Re: [boost] [graph] which algorithm/visitor to use?
by Andrzej Krzemienski 13 May '25

13 May '25

pon., 12 maj 2025 o 00:49 Seth <bugs(a)sehe.nl> napisał(a): > On Sun, May 11, 2025, at 9:53 PM, Andrzej Krzemienski wrote: > > Thanks Seth. This is indeed a solution. But I think it is too heavy for > the task at hand. If I understand this correctly, it will first compute > *every* path between every two airports, only to later discard the too long > ones. The constraint that my problem has -- allow only four or less edges > in the path -- should be able to make the task computationally smaller. > > > It feels like this as a "concern" really has nothing to do with graphs, > and everything with geometry? How about you stuff all the airports in a > boost::geometry::index::rtree and query the nearest until you cross the > threshold distance for both airports (the query results will be in > ascending order of distance - see > https://stackoverflow.com/a/22910024/85371 (include the comments from the > BG devs). > > That moves all the distance calculations out of your hand and puts the > onus of spatial indexing on the BG library. > > I think the rest could be simplified even without the filtered_graph with > just some custom heuristics on astar_search. IIRC the heuristics allow you > to control which edges to examine or skip [Aas opposed to the DFS/BFS > visitors, as you correctly noted.]. I have't used A* as much myself, to be > completely frank. > > Good luck > Thanks. This is an important observation that although I am using something that can be modeled as a graph, using Boost.Graph may be a bad choice. On the other hand, this geographical constraint seems to have drawn most of the attention. But I also expressed another problem: being able to constrain the search to paths limited by the number of edges. Is this also something beyond the scope of Boost.Graph? Is my use case too simplistic for a grah library to be useful? Regards, &rzej;

2 1

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

12 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

Re: [boost] [openmethod] On the unreasonable efficiency of fast_perfect_hash
by Joaquin M López Muñoz 12 May '25

12 May '25

El 12/05/2025 a las 12:06, Ivan Matek escribió: > > > On Sun, May 11, 2025 at 9:01 PM Joaquin M López Muñoz via Boost > <boost(a)lists.boost.org> wrote: > > > https://github.com/joaquintides/perfect_range_hash > > > Thank you for this. Unfortunately even this basic math is a bit too > complex for me > so few small comments: > > 1. stylistically I would link to particular hash of source code, > although documentation > link is nicer. Reason is that documentation link can die I can relink to a more stable doc if the lib is accepted. > 2. afaik C is not randomly chosen between 0<= C <= 2^64, i.e. it is > always an odd number. You're right. We'd have to ask the author, but I guess the "| 1" in "hash_mult = uniform_dist(rnd) | 1" is there to avoid the (very unlikely) case hash_mult = 0. In any case, this small adjustment doesn't change the big picture statistically --the output distribution is largely dominated by C/B, where C is the multiplier and B is 2^(64-m), so the least significant bit of C is mostly swallowed along the way. > 3. in my brief experiments I tried to add large gap, and randomly pick > subset of types, > and performance was still amazing. > > Example for 3.: [...] This case of 231 type_ids scattered in a range of 3000 positions is lower-bounded by (has better chances than) the baseline case with 3000 adjacent positions, which has a probability 0.14 of finding a perfect hash multiplier for 4096 buckets. Note that a "hard" case would involve having your type_ids distributed across the entire 64-bit space of possible numerical values, and in the example you wrote the values are confined to a range that is around 10^14 times smaller than 2^64 --this is the fact that the algorithm takes an implicit advantage of. Joaquin M Lopez Munoz

5 5

[openmethod] On the unreasonable efficiency of fast_perfect_hash
by Joaquin M López Muñoz 12 May '25

12 May '25

Some days ago we discussed the fact that the perfect hashing machinery of candidate Boost.OpenMethod is apparently at odds with the theoretical probability of finding a viable function by chance (i.e. using brute force). I've taken a closer look at this issue and wrote a small article explaining why Boost.OpenMethod's fast_perfect_hash is so exceptionally successful: https://github.com/joaquintides/perfect_range_hash I hope the analysis is of interest to those puzzling over this. Joaquin M Lopez Munoz

2 1

[graph] which algorithm/visitor to use?
by Andrzej Krzemienski 11 May '25

11 May '25

Hi All, I have a graph-related problem that I thought was easy, but I do not seem to be able to find the right tools (algorithms, visitors) in the library to solve it. Maybe someone in the list can give me a hint. I represent airports and their air connections as a graph: * Each airport is a vertex. * There are geographical coordinates associated with each airport. * When there is at least one flight operating between airports A and B, this is represented as an edge. The task is to enumerate all paths between two given vertices U and V, in an efficient way naturally, given the following constraints: 1. The path cannot be composed of more than N edges 2. The path cannot contain a vertex "too far away from U and V", that is, there would be a predicate P that tells for a given vertex W the value P(U, V, W) that tells if vertex W is acceptable. So, I would need a tool that instructs the algorithm that when a certain vertex or an edge is encountered, an algorithm should be skipped on a given branch of the graph, but resume from the next branch. Is there a tool like that in Boost.Graph? Regards, &rzej;

3 4

[OpenMethod] Andrzej's review
by Andrzej Krzemienski 08 May '25

08 May '25

Hi Everyone, This is a review of the proposed Boost.OpenMethod library. First of all, I want to thank Jean-Louis for writing and sharing this library, for undergoing the Boost Review process, and for reviving this interesting and important subject. My recommendation is to *reject* the Boost.OpenMethod library at this time. My decision is based on the design issues. I note that rejection is not a permanent verdict, and there are known Boost libraries that were initially rejected, and then were improved and passed the second review. The library claims to solve two problems: the "expression problem" and the "banana-gorilla-jungle problem". In my opinion, the first problem is not a technical problem worth solving at all. It is more like a logical challenge: can you provide a framework extensible in two dimensions? Maybe I can, but so what? What real program or library benefits from this? The second problem is real, and although the docs do not present it adequately, during the discussion, and also via links to YOMM2 library, Jean-Louis provided a very compelling example of printing a Matrix which is from a OO hierarchy. I am personally not a fan of OO. I use very sparingly anything that has `virtual` on it. For instance, for heavy matrix computations, I would never think of using OO-hierarchies of matrices. It looks to me that OOP is limited in a language without a garbage collection, and any attempts at fixing it can only be limited. The problem is real. I would call it differently: "I want a runtime-polymorphic behavior, but I do not want to commit to all polymorphic functions up front". The library provides a solution for it. It is not necessarily a good solution, and it is for sure not the only solution to the problem. Two other possible solutions: 1. Use std::variant and variant visitors. For a non-trivial motivating example see https://akrzemi1.wordpress.com/2016/02/27/another-polymorphism/ 2. Use OO-style class hierarchies with pattern-matching on top: either wait for the C++ pattern matching, or use a library like Mach7 ( https://github.com/solodon4/Mach7) The docs in OpenMethod are missing the discussion on these alternatives. Especially alternative #2 seems to offer a superior solution, simpler, and with fewer gotchas. It is not clear to me what is the relation between Boost.OpenMethod and N2216. Is the goal to implement N2216? Or is it just mentioned for context, or as a loose inspiration? I hear the replies in the review discussions, "but this is what N2216 said", also the docs say that the library implements N2216 with extensions. But note that N2216 calls itself "a report" and the authors never claimed that they had a solution suitable for standardization. It was an exploration. But the solution in N2216 has one important property: the program would never get a "runtime error" indicating a bad usage of the feature: it would either be a compiler/linker error or an arbitrary -- but *deterministic* -- selection of the overload. N2216 allows no "pure virtual" open methods: it requires that you provide a definition for the "top level" declaration. This way you always have an implementation to fall back to. Also its solution has a consequence that a different overrider can be chosen in different loaded DLLs for the same combination of concrete types. This solution is counterintuitive to me and looks similar to the ODR-violation. It is also possible that two DLLs provide a different overrider for the same combination of types. But this is not surprising. The problem of selecting "the right" overrider (whatever it means, given the two-dimensional flexibility) is not solvable. N2216 makes this lack of a good solution very clear. It also shows how other languages fail to solve it (for instance, requiring a "glue code" to be provided by the person who assembles the final program, which defeats the purpose of the "two dimensional flexibility" of open methods. Anyway, the solution for the overrider selection in N2216 is very different from the one in Boost.OpenMethod, so it is incorrect to say that Boost.OpenMethod implements N2216. It does not. It chose a different approach. In this different approach, you can get a runtime error. Worse still, you can sometimes get a runtime error and sometimes an arbitrary overrider, and it is difficult to remember when which happens. N2216 says that a new linker technology would be required to guarantee no-runtime-error. Boost.OpenMethod seems to lack it. As a consequence, we are getting a feature with a lot of type-safety holes. They are plugged by throwing exceptions and calling std::abort(), but they are still holes: you cannot preemptively prevent them, because of the announced flexibility: anyone can extend the type hierarchy or introduce new open-methods at run-time, via linking a DLL. Boost.OpenMethod is inherently type-unsafe and advertises this as flexibility. It is a common practice for library functions to have *preconditions* and to enforce them by calling std::abort() or throwing an exception, but this works only because the users have the means of controlling the correct usage of a function: sqrt(x); And I could have checked before the call that `x` is negative, or I could have made sure that `x` is the result of summing squares. Because I am in control. But in this call: to_string(matrix); I am not in control of satisfying a precondition, because I do not control what other matrix classes have been added to the hierarchy by other users in other DLLs that I may not even be aware of. This is why exceptions or std::abort() are not a good solution anymore. It is no longer a viable precondition. Another difference between Boost.OpenMethod and N2216 is that in the latter a programmer never says that they are overriding a virtual method. The compiler has to deduce the fact from the signatures. Another difference is that N2216 makes it an error to define a parameter as virtual when a corresponding class s not a reference to a polymorphic type. This is a feature (a safety feature). Boost.OpenMethod does not have it: I can pass any type I want in virtual_ptr only to get an abort at run-time: https://godbolt.org/z/b1Y5zMcfh Given this type of a library, where: * A language feature is implemented as a library * The feature is about declaring interfaces (rather than used for internal implementation, such as BOOST_FOREACH) * The feature itself is controversial and not well explored * It cannot be implemented as a library * The feature is complex I would expect a way more of a discussion and explanations in the documentation. More concepts and definitions. The lack of those, makes me further question the soundness of the design. For one instance, the statement, "Multiple and virtual inheritance are supported, with the exception of repeated inheritance." What does it mean "not to support a form of inheritance"? Compiler error? Run-time abort()? Undefined Behavior? I can check what the current implementation does, but is this guaranteed, or is it a happenstance of the today's implementation? Now, let's compare open methods with pattern matching that can distinguish different concrete classes in a type hierarchy. Regardless if they are language features or library emulations. The type-switch (as in wg21.link/n3449) or "match-expression" (as in wg21.link./p2688) is not devoid of similar problems: Someone may add a new class to the hierarchy after I have implemented my match-expression: double get_area(const Shape& shape) { return shape match { Circle: let [r] => 3.14 * r * r; Rectangle: let [w, h] => w * h; _: throw MyLib::Unimplemented(); }; } And if some new class Polygon now inherits from Shape, I will get a throw. But this time, it is plain clear, written down in my code, in what order the candidates will be considered (up-to-bottom, first match). No surprises of the form, "I thought that X would be a better match". Earlier, I made a claim that the authors of N2216 dropped the idea in favor of pursuing pattern matching. I cannot find any citation that would support this. I guess I got that from the fact that two of the authors of N2216 -- Bjarne Stroustrup and Yuriy Solodkyy -- later wrote papers only on pattern matching (wg21.link/n3449, https://www.stroustrup.com/OpenPatternMatching.pdf) Maybe I got this from the ISO C++ mailing lists. If I understood correctly, the idea behind virtual_ptr is that it should be created early to front-load the expensive hash table look-ups. This tells me that even though I have to use a lot of macros in my interfaces, they are still not able to hide the implementation details, and I am exposed to these details through the pieces of advice, such as "pass around virtual_ptr and store them as members". Then I am exposed to more things, like final_virtual_ptr (not to mention unique_virtual_ptr and shared_virtual_ptr). Here's an important point. Boost is known to deliver language features in form of libraries. But the ones I know were to be used inside function bodies: BOOST_FOREACH, BOOST_AUTO. So my callers do not have to know that I am even using them. It is my business. But with Boost.OpenMethod, we are talking about declaring interfaces. When I -- a library author -- make a choice to use a Boost.OpenMethod-style open method, how do I explain all these quirks to my users? Now I am spilling all those implementation details, micro-decisions, limitations to the poor users. Now, I have a more philosophical question. If we declare open-methods (or even pattern-matching-like type switches) non-intrusively on class hierarchies, these hierarchies no longer need to have virtual functions: he polymorphic behavior can now be implemented as open methods. In that case, what is the purpose of declaring class hierarchies? Previously the answer was clear: the types are in the OO-hierarchy because while they have different implementations, they provide the same interface. Now, with open methods they do not provide the same interface. So why put them into a hierarchy? Every library or a language feature or a tool is a burden: you have to learn it, your users have to learn it, you need to debug it. In order for it to be useful, the costs of usage/maintenance must be outweighed by the benefits of using it. I do not see this being the case for Boost.OpenMethod. This is my main objection. I have smaller observations that could be fixed: * There is a number of mysterious but unexplained terms used, such as "guide functions" or "with the virtual_ decorators stripped". * Things are imported into a global namespace (such as virtual_ptr). Don't do it by default. If users want to see virtual_ptr and final_virtual_ptr as keywords, let them type `using namespace boost::openmethod::keywords;`. * The framework behaves differently based on whether my types are copyable or not. Compare: ** https://godbolt.org/z/zKzYzbj3x ** https://godbolt.org/z/Ya8TrE79K For some standard review questions: * I have played with some toy examples using Clang on Compiler Explorer and using GCC on MinGW on Windows. No problems running the examples. * I spent a couple of days in total, studying the docs, re-reading related papers, running examples, filing bugs, and demonstrating the library in my workplace. * I have kept an eye on the papers on open-methods, open type-switch and pattern matching, playing with Mach7 library. Finally, this review may seem very negative, so let me stress again that I appreciate the work Jean-Louis has done to explore the subject. A critique can be seen as a form of appreciation. Also, thanks to Дмитрий for managing the review. Regards, &rzej;

3 4

Re: [boost] [OpenMethod] review starts on 28th of April
by Ruben Perez 07 May '25

07 May '25

<CC-ing the mailing list, since you just replied me, and answering inline> On Tue, 6 May 2025 at 01:35, Jean-Louis Leroy <jl(a)leroy.nyc> wrote: > > Your example is very similar to > https://jll63.github.io/Boost.OpenMethod/#tutorials_custom_rtti. > > virtual_ptr does not try to use boost_openmethod_vptr in its constructors. That > is an oversight. It is a recent invention. YOMM2 tests for the presence of a > boost_openmethod_vptr instance variable in the object directly. In that context, > the function is very simple and inlinable, but if it is user-defined, there is > no reason to assume that. So I will make virtual_ptr consider it as well. > > Regardless, the easiest way to handle your example is to put the vptr > acquisition in the policy. dynamic_type returns a type_id, not a vptr. The > function for that is dynamic_vptr. It is not part of a facet, eventhough facets > can provide one. The dispatch mechanism is described here: > https://jll63.github.io/Boost.OpenMethod/#ref_description_17 > > WARNING: if you try that code with the "review" branch, make sure to pull the > latest changes, because they fix a bug I introduced while re-establishing checks > for non-polymorphic classes. > > Thus: > > > // ------------------------ > // you > > #include <cstdint> > > enum class kind : std::uintptr_t { unknown, n1, n2 }; > > class base_node { > kind k_; > > protected: > base_node(kind k) noexcept : k_(k) { > } > > public: > kind getKind() const { > return k_; > } > }; > > class node1 : public base_node { > public: > node1() noexcept : base_node(kind::n1) { > } > }; > > class node2 : public base_node { > public: > node2() noexcept : base_node(kind::n2) { > } > }; > > // ------------------------ > // me > > // Get kind from static type, as you RTTI system does not provide it as a > // static member. > > template<typename T> > struct kind_of { > static constexpr kind value = kind::unknown; > }; > > template<> > struct kind_of<node1> { > static constexpr kind value = kind::n1; > }; > > template<> > struct kind_of<node2> { > static constexpr kind value = kind::n2; > }; > > #include <boost/openmethod/policies/basic_policy.hpp> > > struct custom_rtti : boost::openmethod::policies::rtti { > template<class Node> > static constexpr bool is_polymorphic = > std::is_base_of_v<base_node, Node>; > > using type_id = boost::openmethod::type_id; > > template<typename T> > static auto static_type() { > return type_id(kind_of<T>::value); > } > > template<typename T> > static auto dynamic_type(const T& obj) { > if constexpr (is_polymorphic<T>) { > return type_id(obj.getKind()); > } else { > return kind::unknown; > } > } > }; > > struct custom_policy > : boost::openmethod::policies::basic_policy<custom_policy, > custom_rtti> { > > static auto dynamic_vptr(const base_node& b) { > switch (b.getKind()) { > case kind::n1: > return custom_policy::static_vptr<node1>; > case kind::n2: > return custom_policy::static_vptr<node2>; > default: > return custom_policy::static_vptr<base_node>; > } > } > }; > > #define BOOST_OPENMETHOD_DEFAULT_POLICY custom_policy > > #include <iostream> > > #include <boost/openmethod.hpp> > #include <boost/openmethod/compiler.hpp> > > BOOST_OPENMETHOD(process, (std::ostream&, virtual_ptr<base_node>), void); > > BOOST_OPENMETHOD_OVERRIDE( > process, (std::ostream & os, virtual_ptr<node1> node1), void) { > os << "process node1\n"; > } > > BOOST_OPENMETHOD_OVERRIDE( > process, (std::ostream & os, virtual_ptr<node2> node2), void) { > os << "process node2\n"; > } > > BOOST_OPENMETHOD_CLASSES(base_node, node1, node2); > > auto main() -> int { > boost::openmethod::initialize(); > > auto a = std::make_unique<node1>(); > auto b = std::make_unique<node2>(); > > process(std::cout, *a); > process(std::cout, *b); > > return 0; > } > > We could also take advantage of the fact that type_ids fall in a short, compact > range. We can use the vptr_vector facet, but there is no need to hash the > type_ids, we can use them as straight indexes. So we don't use a type_hash > facet: > > struct custom_policy > : boost::openmethod::policies::basic_policy< > custom_policy, custom_rtti, > boost::openmethod::policies::vptr_vector<custom_policy>> {}; > > This time dynamic_vptr() is provided by a facet. Everything else stays the same. For the reference, this is what I ended up doing: enum class kind : std::uintptr_t { unknown, n1, n2 }; class base_node { kind k_; protected: base_node(kind k) noexcept : k_(k) { } public: kind getKind() const { return k_; } }; class node1 : public base_node { public: static constexpr kind node_kind = kind::n1; node1() noexcept : base_node(node_kind) { } }; class node2 : public base_node { public: static constexpr kind node_kind = kind::n2; node2() noexcept : base_node(node_kind) { } }; constexpr const char* kind_to_string(kind k) { switch (k) { case kind::n1: return "node1"; case kind::n2: return "node2"; default: return "<unknown node type>"; } } struct custom_rtti : boost::openmethod::policies::rtti { template<class T> static constexpr bool is_polymorphic = std::is_base_of_v<base_node, T>; template<typename T> static auto static_type() -> std::uintptr_t { if constexpr ( std::is_base_of_v<base_node, T> && !std::is_same_v<base_node, T>) { return static_cast<std::uintptr_t>(T::node_kind); } else { return static_cast<std::uintptr_t>(kind::unknown); } } template<typename T> static auto dynamic_type(const T& obj) -> std::uintptr_t { if constexpr (is_polymorphic<T>) { return static_cast<std::uintptr_t>(obj.getKind()); } else { return static_cast<std::uintptr_t>(kind::unknown); } } template<class Stream> static void type_name(std::uintptr_t type, Stream& stream) { stream << kind_to_string(static_cast<kind>(type)); } }; struct custom_policy : boost::openmethod::policies::basic_policy< custom_policy, custom_rtti, boost::openmethod::policies::runtime_checks, boost::openmethod::policies::basic_error_output<custom_policy>, boost::openmethod::policies::vptr_vector<custom_policy>> {}; BOOST_OPENMETHOD_CLASSES(base_node, node1, node2, custom_policy) BOOST_OPENMETHOD(print, (virtual_<base_node>), void, custom_policy); BOOST_OPENMETHOD_OVERRIDE(print, (base_node&), void) { /* whatever */ } I've just realized that I've disabled hashing by accident, and this happened to work by accident. I think that this implicit dependency between the vptr_vector and the hashing policy is a problem - I prefer explicit dependencies. > > As you see in this example, we don't have to fork policies, we can just > construct them from scratch. Forking was introduced with the idea of tuning > default_policy, without having to replicate it from scratch. Also the > with/without setters are less verbose than the add/replace/remove ones. > > Elsewhere I said that facets categories are a closed set. That is not correct. > The dispatcher and the compiler look only at a closed set of facets > (using if constexpr (Policy::has_facet>)). But some facets, like vptr_vector and > error_handler, look for other facets in the policy, which are not necessarily > referenced directly by the compiler or the dispatcher. In that sense, the set of > facets is actually open. > > I am going to think about your suggested alternative to the facet system. > Seriously, thus it will take me a few days. In the meantime, how would you see > the two example policies above, expressed with your system? This is what it'd look like with my proposal: struct custom_rtti : openmethod::policies::rtti { template<class T> static constexpr bool is_polymorphic = std::is_base_of_v<base_node, T>; template<typename T> auto static_type() const -> std::uintptr_t { /* same definition */ } template<typename T> auto dynamic_type(const T& obj) const -> std::uintptr_t { /* same definition */ } template<class Stream> void type_name(std::uintptr_t type, Stream& stream) const { /* same definition */ } }; struct custom_policy : boost::openmethod::policies::abstract_policy { // enable runtime checks openmethod::policies::runtime_checks runtime_checks; // enable the default error output openmethod::policies::basic_error_output<> error_output; // pass the hashing policy to vptr_vector explicitly, rather than implicitly via the entire Policy // disable_hashing should be either a marker type to tell vptr_vector "I don't have any hashing available" // or implement the type_hash facet and be a no-op (I guess the 1st option is better) openmethod::policies::vptr_vector<openmethod::policies::disable_hashing> extern_vptr; }; // Now register the classes. See below for the definition of registry BOOST_OPENMETHOD_CLASSES(base_node, node1, node2, openmethod::registry<custom_policy>) BOOST_OPENMETHOD(print, (virtual_<base_node>), void, openmethod::registry<custom_policy>); BOOST_OPENMETHOD_OVERRIDE(print, (base_node&), void) { /* whatever */ } // This type needs to be provided by the library, and is in charge of creating the required static storage namespace boost::openmethod { template <class Policy> struct registry { using policy_type = Policy; static Policy policy; }; } There are likely things I'm not seeing now that will probably complicate this. If the review is favorable, I can write a PR with the proposed changes and see if it's viable. > > I would love to ship a fully functional clang RTTI policy right off the bat; it > is an important use-case. > > J-L Thanks, Ruben.

2 3

A proposal for a modern build-system
by Hassan Sajjad 07 May '25

07 May '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

9 24

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] Few questions about unreasonable effectiveness of fast_perfect_hash and other minor things
by Ivan Matek 02 May '25

02 May '25

Hi everyone, few questions: 1. fast_perfect_hash achieves performance(load factor) I would assume is impossible, based on perfect hashing talk <https://www.youtube.com/watch?v=yOo6GnbKzp8>. I presume reason why it works so well that compiler places type info data clustered in same region of addresses... Is that correct? 2. regarding static_list: would Boost.Intrusive list work here also, and if so was this considered? 3. basic_error_output does not seem to need the Policy template parameter, is this left for consistency or am I wrong that it is not needed? 4. dynamic_cast_ref docs <https://github.com/jll63/Boost.OpenMethod/blob/ea7dbe86b511797f0281ef07b3ad…> mention that D must match the reference category of B. Would it be possible to static_assert that?

3 5

[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 22 Apr '25

22 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 24

[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

1 0

[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 11 Apr '25

11 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

is is possible to downsize the boost installation folder
by Dennis Luehring 10 Apr '25

10 Apr '25

im building boost 1.87 and i only need thread+asio building: cd /home/test wget https://archives.boost.io/release/1.87.0/source/boost_1_87_0.tar.bz2 tar -xf boost_1_87_0.tar.bz2 cd boost_1_87_0 ./bootstrap.sh --prefix=/home/test/boost_1_87_0_installed ./b2 variant=release --with-thread install the resulting install folder /home/test/boost_1_87_0_installed lib folder is ~500 KB include is ~142 MB is it possible to only have the needed library includes in the include folder?

3 3

[release] Boost 1.88.0 Release Candidate 1 is available
by Marshall Clow 10 Apr '25

10 Apr '25

The first release candidates for the 1.88.0 release are now available at: <https://archives.boost.io/release/1.88.0/source/> The SHA256 checksums are as follows: 8ee21476f1aca1978339f0f4a218b9b8a6746eec83070f32630f97b09c7e91b7 boost_1_88_0_rc1.zip e84a33716a31c1c8cb00783a411630d41c008e9364002dc0fe55aea4f54f4726 boost_1_88_0_rc1.7z 46d9d2c06637b219270877c9e16155cbd015b6dc84349af064c088e9b5b12f7b boost_1_88_0_rc1.tar.bz2 3621533e820dcab1e8012afd583c0c73cf0f77694952b81352bf38c1488f9cb4 boost_1_88_0_rc1.tar.gz 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

6 7

[OpenMethod] review
by Дмитрий Архипов 10 Apr '25

10 Apr '25

I'm trying to get a Boost review scheduled for the proposed Boost.OpenMethod. I sent an email directly to review wizards but haven't gotten a response. Can anyone help me get in touch with the wizards?

5 6

[bloom] Candidate Boost Bloom library: request for endorsements
by Joaquin M López Muñoz 09 Apr '25

09 Apr '25

Hi, I've been working during the last few months in a library I would like to propose for Boost: Repo: https://github.com/joaquintides/bloom Docs: https://master.bloom.cpp.al/ (Candidate) Boost.Bloom provides the class template boost::bloom::filter that can be configured to implement a classical Bloom filter as well as variations discussed in the literature such as block filters, multiblock filters, and more. #include <boost/bloom/filter.hpp> #include <cassert> #include <string> int main() { // Bloom filter of strings with 5 bits set per insertion using filter = boost::bloom::filter<std::string, 5>; // create filter with a capacity of 1'000'000 **bits** filter f(1'000'000); // insert elements (they can't be erased, Bloom filters are insert-only) f.insert("hello"); f.insert("Boost"); //... // elements inserted are always correctly checked as such assert(f.may_contain("hello") == true); // elements not inserted may incorrectly be identified as such with a // false positive rate (FPR) which is a function of the array capacity, // the number of bits set per element and generally how the boost::bloom::filter // was specified if(f.may_contain("bye")) { // likely false //... } } If you deem the library interesting and think it stands a chance of being accepted into Boost, allow me to request your endorsement. Best, Joaquin M Lopez Munoz

3 2

Call traits
by Robert Jones 07 Apr '25

07 Apr '25

Hi All Has the meat of Boost Call Traits ever made it into the stdlib? It seems like an obvious candidate, but I can't see it. Stdlin <type_traits> seems to be a very different offering, but maybe I'm missing something? Kind Regards Rob.

2 1

Which boost version/Asio fully supports Windows XP and how to build that from source?
by Dennis Luehring 04 Apr '25

04 Apr '25

i want to migrate an old dirty legacy app handling TCP/IP to Boost.Asio because all my other TCP/IP stuff is using Asio and the legacy app getting reworked BUT it still needs to run on old dirty Windows XP - for around 1-2 years (then i can upgrade to more recent compiler/Boost etc.) i know that i had used Boost (i think 1.69) on XP a long time ago and trying to find out what Boost version is the last XP supporting and how i can build boost from source with VS2022 + v141_xp toolkit (if that is even possible - i have no idea) im using boost on daily basis and build for Linux,Windows for over a decade so its just the Windows XP thing that makes mit nervous tried building Boost 1.69 seems to be possible with VS2022 x86 console with v141_xp toolkit installed (not tested with XP so far) boostrap.bat vc141 and i think that is minimal needed for Asio b2 release toolset=msvc-14.1 define=BOOST_USE_WINAPI_VERSION=0x0501 --with-system --with-thread --with-date_time --with-regex --with-serialization stage toolset can be set to anything currently (even msvc-14.1_xp or msv-14.1_blabla) so im not sure what i really need to force using the v141_xp toolkit so what is the latest Boost version that supports XP enough for Asio use and how to build that one properbly? thanks for any help

2 3

[release] Master branch is now closed for the release
by Marshall Clow 03 Apr '25

03 Apr '25

Master is closed for all changes. See the release schedule at: https://www.boost.org/development/index.html -- Release managers

1 0

[release] Master branch is now open for bug fixes
by Marshall Clow 02 Apr '25

02 Apr '25

Hi, The master branch is now open for bug fixes, test and documentation changes, but please follow the policy described in: https://github.com/boostorg/wiki/wiki/Releases%3A-Beta-Merge-Policy The next deadline: On April 2nd, master closes for all changes. As always, the calendar is at https://www.boost.org/development/ — The release managers

4 3

Boost::MQTT5 and boost 1.82.0?
by Georg Gast 31 Mar '25

31 Mar '25

Hi Boost, i read here [1] that boost::mqtt5 needs boost 1.82.0 but it is published with 1.88.0 Beta1 How to use boost::mqtt5 with boost 1.82.0? > Boost.MQTT5 is a header-only library. To use Boost.MQTT5 it requires the following: > > C++17 capable compiler > Boost 1.82 or later. In addition to Asio, we use other header- >only libraries. > OpenSSL. If you require an SSL connection by using boost::asio::ssl::stream. [1] https://www.boost.org/doc/libs/1_88_0_beta1/libs/mqtt5/doc/html/mqtt5/intro…

2 2

Issue fixed in context library that is not included in 1.88 beta release?
by Anders Axelsson 29 Mar '25

29 Mar '25

Hi, I stumbled upon a problem found in the 1.87.0 release (and also 1.88 beta1) The issue seems to have been resolved on the develop branch in the actual submodule repo quite some time ago by another developer, but it is yet not included in the top/super project. The ticket: https://github.com/boostorg/context/issues/297 I am very new to the community, so I don't really know what is the typical way of working here. it would be sad if we miss to include an important build issue in the next release just because of some administrative issues, so I am happy to help but like I said, I am not familiar with how I can do that. Any ideas?

3 3

Asio Beta changes are missing on the 1.88 Beta page
by Dennis Luehring 27 Mar '25

27 Mar '25

Asio is missing on the beta release page https://www.boost.org/users/history/version_1_88_0.html but there seem to be changes available for the beta https://www.boost.org/doc/libs/1_88_0_beta1/doc/html/boost_asio/history.html

1 0

Reminder: Master branch closes for the 1.88.0 release NEXT WEDNESDAY
by Marshall Clow 26 Mar '25

26 Mar '25

Also, if you have release notes, now’s the time to write them. — Marshall

1 0

release] Boost 1.88.0 beta 1 released
by Marshall Clow 16 Mar '25

16 Mar '25

Boost release 1.88.0 beta 1 is now available at: https://archives.boost.io/beta/1.88.0.beta1/source/ The SHA256 checksums are: bc4948bc664fde0c2142badae2679a42124b464dc58019250afe0ef57fd7763e boost_1_88_0_rc1.zip 3c334a9a743b68a35452b0223be8932fb39f26a6938382f9b9e625c4df99602c boost_1_88_0_rc1.tar.gz 9e42c0611500151d795d66a07ef0a21036c02d24678e2e887caf6d97fcbc25ca boost_1_88_0_rc1.tar.bz2 7faf60c4cb12ee90270e41716cf3735a8739016d7346983ce9f5e899e510b26d boost_1_88_0_rc1.7z Release notes (still need updates): https://www.boost.org/users/history/version_1_88_0.html Please try the beta and report any problems you encounter. Thanks to everyone who contributed to the release. -- Boost Release Team

3 2

[release] Boost 1.88.0 Release Candidate 1 is available
by Marshall Clow 14 Mar '25

14 Mar '25

Available at: https://archives.boost.io/beta/1.88.0.beta1/source/ The SHA256 checksums are as follows: bc4948bc664fde0c2142badae2679a42124b464dc58019250afe0ef57fd7763e boost_1_88_0_b1_rc1.zip 3c334a9a743b68a35452b0223be8932fb39f26a6938382f9b9e625c4df99602c boost_1_88_0_b1_rc1.tar.gz 9e42c0611500151d795d66a07ef0a21036c02d24678e2e887caf6d97fcbc25ca boost_1_88_0_b1_rc1.tar.bz2 7faf60c4cb12ee90270e41716cf3735a8739016d7346983ce9f5e899e510b26d boost_1_88_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

7 10

[proposal] OpenMethod library
by Jean-Louis Leroy 11 Mar '25

11 Mar '25

Hello Boost developers! I would like to propose my open-method library for inclusion in Boost. Open-methods are an elegant solution to the Expression Problem: > Given a set of types, and a set of operations on these types, is it possible > to add new operations on the existing types, and new types to the existing > operations, without modifying existing code? Open-methods solve the Expression Problem by making it possible to define free virtual functions, i.e. virtual functions that exist outside of a class. They also help reduce coupling. Open-methods are often called "multi-methods", because they typically make it possible to select an overrider on the basis of more than one argument (as this library does). Nice, but this is a distraction. Observations show that single dispatch largely outnumbers multiple dispatch in real systems, even in languages that natively support multi-methods (Common Lisp, Clojure, Julia, Dylan, TADS, Cecil, Diesel, Nice, etc). "Multi" is just the cherry on the "open" cake. Bjarne Stroustrup wanted open-methods in C++ almost from the beginning. In D&E he writes: > I repeatedly considered a mechanism for a virtual function call based on more > than one object, often called multi-methods. [...] Since about 1985, I have > always felt some twinge of regret for not providing multi-methods. > Stroustrup, 1994, The Design and Evolution of C++, 13.8. Circa 2007, he tried to bring open-methods into the standard, unfortunately without success, to his enduring regret. Decades later he writes: > In retrospect, I don’t think that the object-oriented notation (e.g., x.f(y)) > should ever have been introduced. The traditional mathematical notation f(x,y) > is sufficient. As a side benefit, the mathematical notation would naturally > have given us multi-methods, thereby saving us from the visitor pattern > workaround. > Stroustrup, 2020, Thriving in a Crowded and Changing World: C++ 2006–2020. This is what this library is all about: f(x, y), and getting rid of visitors. It closely follows the design described in the papers by Stroustrup and his PhD students Peter Pirkelbauer and Yuriy Solodkyy. Method dispatch is *fast*. It uses v-tables similar to native virtual functions, and it can match their performance. The library also provides additional features: a mechanism to call the next most specialized overrider, support for smart pointers, customization points for alternative RTTI systems, error handling, tracing, etc. The library requires C++17 or above. It supports virtual and multiple inheritance, excluding repeated inheritance. For evaluation purposes, I prepared a repository with a library adapted to Boost naming conventions: https://github.com/jll63/Boost.OpenMethod. The documentation is here: https://jll63.github.io/Boost.OpenMethod. Here are a few examples from the tutorial on Compiler Explorer: * Hello World: https://godbolt.org/z/9hv8oE8zd * AST - combining virtual_ptr and std::unique_ptr: https://godbolt.org/z/cPjzfanc8 * Intrusive vptr: https://godbolt.org/z/87h9zv7dK * Policy for throwing exceptions: https://godbolt.org/z/nEYWGsPc5 If you like what you see, please consider endorsing the library. Thanks, Jean-Louis Leroy

6 11

[Release] Master branch is now closed for the beta release
by Marshall Clow 09 Mar '25

09 Mar '25

Master is closed for all changes. See the release schedule at: https://www.boost.org/development/index.html -- Release managers

1 0

[release] Master branch closes for the 1.88.0 beta release on SATURDAY (March 8)
by Ion Gaztañaga 06 Mar '25

06 Mar '25

Hi, Due to some unexpected delays, the master branch will close on SATURDAY (March 8). — The Release Managers

1 0

MAP and Vector clear is not releasing memory
by Murali Kishore 26 Feb '25

26 Feb '25

Hi, map and vector stored in shared memory using boost apis and called clear to release memory. when i insert same key i see old data present. want to check using boost map.clear or vec.clear is not removing content. Example: pod_list[] (vector contains following 3 members) pod_info { pod_id du_map. cell_map. } Step 1: Added elements Step 2: pod_list.clear(); Step 3: observed no elements in pod_list empty Step 4: Added only key pod_info.pod_id = 1; pod_list.insert(pod_info); Step 5: i see old content map to this pod_id. after this expecting du_map.size and cell_map size is empty. but du_map,cell_map content is same as before clear want to check is clear will not remove memory? is any other best way to clean this vector. -- Regards, Murali Kishore

2 2

Master branch now closed for new libraries and breaking changes
by Marshall Clow 26 Feb '25

26 Feb '25

Welcome to the start of the 1.88.0 release cycle. The release branch is now closed for new libraries and breaking changes to existing libraries. Still open for bug fixes and other routine changes to all libraries without release manager review. The next deadline is next Wednesday, when the release branch will be closed for major changes. As always, the calendar is here: https://www.boost.org/development/index.html — The release managers

2 1

Master branch closing for major changes TOMORROW
by Marshall Clow 26 Feb '25

26 Feb '25

After tomorrow: Release branch closed for major code changes. Still open for serious problem fixes and docs changes without release manager review. Next milestone:March 5th - Release closed for all changes (for 1.88.0 beta 1) Calendar is here: https://www.boost.org/development/ — The release managers

1 0

observing crash during find_or_construct
by Murali Kishore 25 Feb '25

25 Feb '25

Hi all, Now i have moved most of the containers into shared memory, i am Observing crash at random places while calling find_or_construct api, trace as below, what might be reasons for this behaviour and how to get more debug info in these type of errors. #0 operator() (this=<optimized out>, b=..., i=...) at /staging/cu/x86/include/boost/interprocess/indexes/iset_index.hpp:94 #1 operator()<boost::interprocess::ipcdetail::intrusive_compare_key<char> > (this=<optimized out>, key2=..., nonkey1=...) at /staging/cu/x86/include/boost/intrusive/detail/tree_value_compare.hpp:157 #2 operator()<boost::interprocess::ipcdetail::intrusive_compare_key<char>, boost::interprocess::offset_ptr<boost::intrusive::compact_rbtree_node<boost::interprocess::offset_ptr<void> >, long int, long unsigned int, 0ul> > (this=<optimized out>, t2=..., t1=...) at /staging/cu/x86/include/boost/intrusive/detail/key_nodeptr_comp.hpp:106 #3 insert_unique_check<boost::interprocess::ipcdetail::intrusive_compare_key<char>, boost::intrusive::detail::key_nodeptr_comp<boost::interprocess::iset_index<boost::interprocess::ipcdetail::index_config<char, boost::interprocess::rbtree_best_fit<boost::interprocess::mutex_family> > >::intrusive_key_value_less, boost::intrusive::bhtraits<boost::interprocess::ipcdetail::intrusive_value_type_impl<boost::intrusive::generic_hook<(boost::intrusive::algo_types)5, boost::intrusive::rbtree_node_traits<boost::interprocess::offset_ptr<void>, true>, boost::intrusive::dft_tag, (boost::intrusive::link_mode_type)1, (boost::intrusive::base_hook_type)3>, char, unsigned long>, boost::intrusive::rbtree_node_traits<boost::interprocess::offset_ptr<void>, true>, (boost::intrusive::link_mode_type)1, boost::intrusive::dft_tag, 3u>, boost::move_detail::identity<boost::interprocess::ipcdetail::intrusive_value_type_impl<boost::intrusive::generic_hook<(boost::intrusive::algo_types)5, boost::intrusive::rbtree_node_traits<boost::interprocess::offset_ptr<void>, true>, boost::intrusive::dft_tag, (boost::intrusive::link_mode_type)1, (boost::intrusive::base_hook_type)3>, char, unsigned long> > > > (pdepth=0x0, commit_data=..., comp=..., key=..., header=...) at /staging/cu/x86/include/boost/intrusive/bstree_algorithms.hpp:1014 #4 boost::intrusive::bstbase2<boost::intrusive::bhtraits<boost::interprocess::ipcdetail::intrusive_value_type_impl<boost::intrusive::generic_hook<(boost::intrusive::algo_types)5, boost::intrusive::rbtree_node_traits<boost::interprocess::offset_ptr<void, long, unsigned long, 0ul>, true>, boost::intrusive::dft_tag, (boost::intrusive::link_mode_type)1, (boost::intrusive::base_hook_type)3>, char, unsigned long>, boost::intrusive::rbtree_node_traits<boost::interprocess::offset_ptr<void, long, unsigned long, 0ul>, true>, (boost::intrusive::link_mode_type)1, boost::intrusive::dft_tag, 3u>, void, void, (boost::intrusive::algo_types)5, void>::insert_unique_check<boost::interprocess::ipcdetail::intrusive_compare_key<char>, boost::interprocess::iset_index<boost::interprocess::ipcdetail::index_config<char, boost::interprocess::rbtree_best_fit<boost::interprocess::mutex_family, boost::interprocess::offset_ptr<void, long, unsigned long, 0ul>, 0ul> > >::intrusive_key_value_less> (this=this@entry=0x7f035d1dc0a0, key=..., comp=..., commit_data=...) at /staging/cu/x86/include/boost/intrusive/bstree.hpp:499 #5 0x0000000001d8c7a1 in insert_check<boost::interprocess::ipcdetail::intrusive_compare_key<char>, boost::interprocess::iset_index<boost::interprocess::ipcdetail::index_config<char, boost::interprocess::rbtree_best_fit<boost::interprocess::mutex_family> > >::intrusive_key_value_less> (commit_data=..., key=..., this=0x7f035d1dc098, comp=...) at /staging/cu/x86/include/boost/intrusive/set.hpp:232 #6 insert_check (commit_data=..., key=..., this=0x7f035d1dc098) at /staging/cu/x86/include/boost/interprocess/indexes/iset_index.hpp:138 #7 priv_generic_named_construct<char> (type=1 '\001', is_intrusive=..., index=..., table=..., dothrow=true, try2find=true, num=1, name=0x7f03504a1cd0 "is_xn_setup_failed_alarm_raised", this=<optimized out>, this=<optimized out>) at /staging/cu/x86/include/boost/interprocess/segment_manager.hpp:1096 #8 priv_generic_construct (table=..., dothrow=true, try2find=true, num=1, name=0x7f03504a1cd0 "is_xn_setup_failed_alarm_raised", this=0x7f035d1dc010) at /staging/cu/x86/include/boost/interprocess/segment_manager.hpp:760 #9 generic_construct<bool> (table=..., dothrow=true, try2find=true, num=1, name=0x7f03504a1cd0 "is_xn_setup_failed_alarm_raised", this=0x7f035d1dc010) at /staging/cu/x86/include/boost/interprocess/segment_manager.hpp:704 #10 boost::interprocess::ipcdetail::named_proxy<boost::interprocess::segment_manager<char, boost::interprocess::rbtree_best_fit<boost::interprocess::mutex_family, boost::interprocess::offset_ptr<void, long, unsigned long, 0ul>, 0ul>, boost::interprocess::iset_index>, bool, false>::operator()<bool>(bool&&) const (this=<optimized out>) at /staging/cu/x86/include/boost/interprocess/detail/named_proxy.hpp:132 #11 0x0000000001fbb6c8 in gnb::gnb_mgr_neighbour::gnb_mgr_neighbour (this=0x7f033815fc50, segment_manager=0x7f035d1dc010, id=<optimized out>) at /../src/gnb_mgr_db_neighbour.cpp:76 #12 0x0000000002062888 in gnb::gnb_mgr_anr_nrt::add_anr_gnb_mgr_neighbour_target (this=0x7f033815a4c0, neighbour_gnb_id=108, neighbour_xnc_ip_address=..., type=0, neighbour_tac=101, amf_id=3, neighbour_plmn_id=...) at /../src/gnb_mgr_anr_nrt.cpp:1415 #13 0x0000000002325356 in gnb::gnb_mgr_amf::amf_fsm::process_downlink_ran_configuration_transfer (this=this@entry=0x7f035d1e0618, gnb_mgr_amf=gnb_mgr_amf@entry=0x7f0338109070, msg=msg@entry=0x7f0338161bd0) at /../src/gnb_mgr_db_amf.cpp:2851 #14 0x000000000235518b in gnb::gnb_mgr_amf::amf_fsm::process_amf_state_ng_setup_complete (this=<optimized out>, event=gnb::gnb_mgr_amf::EVENT_DOWNLINK_RAN_CONFIGURATION_TRANSFER, gnb_mgr_amf=0x7f0338109070, msg=0x7f0338161bd0, this=<optimized out>, this=<optimized out>, this=<optimized out>, this=<optimized out>, this=<optimized out>, this=<optimized out>, this=<optimized out>, this=<optimized out>, this=<optimized out>, this=<optimized out>, this=<optimized out>, this=<optimized out>, this=<optimized out>, this=<optimized out>, this=<optimized out>, this=<optimized out>, this=<optimized out>, this=<optimized out>, this=<optimized out>, this=<optimized out>, this=<optimized out>, this=<optimized out>, this=<optimized out>, this=<optimized out>, this=<optimized out>, this=<optimized out>, this=<optimized out>) at /../src/gnb_mgr_db_amf.cpp:3122 #15 0x0000000002362a01 in gnb::gnb_mgr_amf::amf_fsm::process_amf_fsm (this=<optimized out>, event=gnb::gnb_mgr_amf::EVENT_DOWNLINK_RAN_CONFIGURATION_TRANSFER, gnb_mgr_amf=0x7f0338109070, msg=0x7f0338161bd0, this=<optimized out>, this=<optimized out>, this=<optimized out>, this=<optimized out>, this=<optimized out>, this=<optimized out>, this=<optimized out>, this=<optimized out>, this=<optimized out>, this=<optimized out>, this=<optimized out>, this=<optimized out>, this=<optimized out>, this=<optimized out>) at /../src/gnb_mgr_db_amf.cpp:4713 #16 0x0000000002362ee7 in gnb::gnb_mgr_amf::process_amf_current_state (this=<optimized out>, event=event@entry=gnb::gnb_mgr_amf::EVENT_DOWNLINK_RAN_CONFIGURATION_TRANSFER, gnb_mgr_amf=<optimized out>, msg=msg@entry=0x7f0338161bd0, this=<optimized out>) at /../src/gnb_mgr_db_amf.cpp:4820 #17 0x00000000021906b0 in gnb::gnb_mgr_ng_msg_proc::process_downlink_ran_configuration_transfer (this=<optimized out>, sctp_common_msg_rx_ind_info=sctp_common_msg_rx_ind_info@entry=0x7f033c040430) at /../src/gnb_mgr_ng_msg.cpp:1456 #18 0x00000000021a20c9 in gnb::gnb_mgr_ng_msg_proc::process_ng_msg (this=this@entry=0x7f03504a4640, sctp_common_msg_rx_ind_info=sctp_common_msg_rx_ind_info@entry=0x7f033c040430) at /../src/gnb_mgr_ng_msg.cpp:2199 #19 0x00000000024d991c in gnb::gnb_mgr_msg_hdlr::process_sctp_common_msg_rx_ind (this=<optimized out>, sctp_common_msg_rx_ind=0x7f033c040430) at /../src/gnb_mgr_msg_hdlr.cpp:3807 #20 0x0000000001db5ea2 in gnb::common_cntrl_thread::process_message (this=0xd825da0, message=0x7f033c120d50) at ../src/common_cntrl_thread.cpp:2418 #21 0x0000000001ceaeec in ngp::comm_thread::run (this=0xd825da0) at /include/ngp_comm_thread.h:220 #22 0x0000000002758e07 in thread_entry_function (param=0xd825da0) at /thread/build/../src/ngp_sys_thread.cpp:111 #23 ngp::thread_start (param=0xd825da0) at /thread/build/../src/ngp_sys_thread.cpp:124 #24 0x00007f036ba90ea5 in start_thread () from /lib64/libpthread.so.0 #25 0x00007f036b7b9b0d in clone () from /lib64/libc.so.6 #0 operator() (this=<optimized out>, b=..., i=...) at /staging/cu/x86/include/boost/interprocess/indexes/iset_index.hpp:94 blen = <optimized out> #1 operator()<boost::interprocess::ipcdetail::intrusive_compare_key<char> > (this=<optimized out>, key2=..., nonkey1=...) at /staging/cu/x86/include/boost/intrusive/detail/tree_value_compare.hpp:157 No locals. #2 operator()<boost::interprocess::ipcdetail::intrusive_compare_key<char>, boost::interprocess::offset_ptr<boost::intrusive::compact_rbtree_node<boost::interprocess::offset_ptr<void> >, long int, long unsigned int, 0ul> > (this=<optimized out>, t2=..., t1=...) at /staging/cu/x86/include/boost/intrusive/detail/key_nodeptr_comp.hpp:106 No locals. #3 insert_unique_check<boost::interprocess::ipcdetail::intrusive_compare_key<char>, boost::intrusive::detail::key_nodeptr_comp<boost::interprocess::iset_index<boost::interprocess::ipcdetail::index_config<char, boost::interprocess::rbtree_best_fit<boost::interprocess::mutex_family> > >::intrusive_key_value_less, boost::intrusive::bhtraits<boost::interprocess::ipcdetail::intrusive_value_type_impl<boost::intrusive::generic_hook<(boost::intrusive::algo_types)5, boost::intrusive::rbtree_node_traits<boost::interprocess::offset_ptr<void>, true>, boost::intrusive::dft_tag, (boost::intrusive::link_mode_type)1, (boost::intrusive::base_hook_type)3>, char, unsigned long>, boost::intrusive::rbtree_node_traits<boost::interprocess::offset_ptr<void>, true>, (boost::intrusive::link_mode_type)1, boost::intrusive::dft_tag, 3u>, boost::move_detail::identity<boost::interprocess::ipcdetail::intrusive_value_type_impl<boost::intrusive::generic_hook<(boost::intrusive::algo_types)5, boost::intrusive::rbtree_node_traits<boost::interprocess::offset_ptr<void>, true>, boost::intrusive::dft_tag, (boost::intrusive::link_mode_type)1, (boost::intrusive::base_hook_type)3>, char, unsigned long> > > > (pdepth=0x0, commit_data=..., comp=..., key=..., header=...) at /staging/cu/x86/include/boost/intrusive/bstree_algorithms.hpp:1014 depth = <optimized out> y = { internal = { m_offset = 769371974, alignment_helper = { dummy = "F\257\333-\000\000\000" } } } left_child = true not_present = <optimized out> h = { internal = { m_offset = 215197376, alignment_helper = { dummy = "\300\246\323\f\000\000\000" } } } x = { internal = { m_offset = 769371958, alignment_helper = { dummy = "6\257\333-\000\000\000" } } } prev = { internal = { m_offset = 215199488, alignment_helper = { dummy = "\000\257\323\f\000\000\000" } } } #4 boost::intrusive::bstbase2<boost::intrusive::bhtraits<boost::interprocess::ipcdetail::intrusive_value_type_impl<boost::intrusive::generic_hook<(boost::intrusive::algo_types)5, boost::intrusive::rbtree_node_traits<boost::interprocess::offset_ptr<void, long, unsigned long, 0ul>, true>, boost::intrusive::dft_tag, (boost::intrusive::link_mode_type)1, (boost::intrusive::base_hook_type)3>, char, unsigned long>, boost::intrusive::rbtree_node_traits<boost::interprocess::offset_ptr<void, long, unsigned long, 0ul>, true>, (boost::intrusive::link_mode_type)1, boost::intrusive::dft_tag, 3u>, void, void, (boost::intrusive::algo_types)5, void>::insert_unique_check<boost::interprocess::ipcdetail::intrusive_compare_key<char>, boost::interprocess::iset_index<boost::interprocess::ipcdetail::index_config<char, boost::interprocess::rbtree_best_fit<boost::interprocess::mutex_family, boost::interprocess::offset_ptr<void, long, unsigned long, 0ul>, 0ul> > >::intrusive_key_value_less> (this=this@entry=0x7f035d1dc0a0, key=..., comp=..., commit_data=...) at /staging/cu/x86/include/boost/intrusive/bstree.hpp:499 ret = { first = { internal = { m_offset = 769371910, alignment_helper = { dummy = "\006\257\333-\000\000\000" } } }, second = true } #5 0x0000000001d8c7a1 in insert_check<boost::interprocess::ipcdetail::intrusive_compare_key<char>, boost::interprocess::iset_index<boost::interprocess::ipcdetail::index_config<char, boost::interprocess::rbtree_best_fit<boost::interprocess::mutex_family> > >::intrusive_key_value_less> (commit_data=..., key=..., this=0x7f035d1dc098, comp=...) at /staging/cu/x86/include/boost/intrusive/set.hpp:232 No locals. #6 insert_check (commit_data=..., key=..., this=0x7f035d1dc098) at /staging/cu/x86/include/boost/interprocess/indexes/iset_index.hpp:138 No locals. #7 priv_generic_named_construct<char> (type=1 '\001', is_intrusive=..., index=..., table=..., dothrow=true, try2find=true, num=1, name=0x7f03504a1cd0 "is_xn_setup_failed_alarm_raised", this=<optimized out>, this=<optimized out>) at /staging/cu/x86/include/boost/interprocess/segment_manager.hpp:1096 key = { mp_str = 0x7f03504a1cd0 "is_xn_setup_failed_alarm_raised", m_len = 31 } insert_ret = { first = { static stateful_value_traits = false, members_ = { nodeptr_ = { internal = { m_offset = 1, alignment_helper = { dummy = "\001\000\000\000\000\000\000" } } } } }, second = false } intrusive_hdr = <optimized out> block_info = { m_value_bytes = 1, m_num_char = 31, m_value_alignment = 1 '\001', m_alloc_type_sizeof_char = 33 '!' } commit_data = { link_left = 112, node = { internal = { m_offset = 1, alignment_helper = { dummy = "\001\000\000\000\000\000\000" } } } } hdr = <optimized out> ptr = <optimized out> name_ptr = <optimized out> it = { static stateful_value_traits = false, members_ = { nodeptr_ = { internal = { m_offset = 1, alignment_helper = { dummy = "\001\000\000\000\000\000\000" } } } } } buffer_ptr = <optimized out> v_eraser = { m_cont = @0x0, m_index_it = { static stateful_value_traits = false, members_ = { nodeptr_ = { internal = { m_offset = 0, alignment_helper = { dummy = "\000\000\000\000\000\000\000" } } } } }, m_erase = 208 } #8 priv_generic_construct (table=..., dothrow=true, try2find=true, num=1, name=0x7f03504a1cd0 "is_xn_setup_failed_alarm_raised", this=0x7f035d1dc010) at /staging/cu/x86/include/boost/interprocess/segment_manager.hpp:760 No locals. #9 generic_construct<bool> (table=..., dothrow=true, try2find=true, num=1, name=0x7f03504a1cd0 "is_xn_setup_failed_alarm_raised", this=0x7f035d1dc010) at /staging/cu/x86/include/boost/interprocess/segment_manager.hpp:704 No locals. #10 boost::interprocess::ipcdetail::named_proxy<boost::interprocess::segment_manager<char, boost::interprocess::rbtree_best_fit<boost::interprocess::mutex_family, boost::interprocess::offset_ptr<void, long, unsigned long, 0ul>, 0ul>, boost::interprocess::iset_index>, bool, false>::operator()<bool>(bool&&) const (this=<optimized out>) at /staging/cu/x86/include/boost/interprocess/detail/named_proxy.hpp:132 ctor_obj = <unknown type in /bin/gnb_cu_cp_gnb_mgr, CU 0x14204b9, DIE 0x1522041> -- Regards, Murali Kishore

1 0

Introduction & Inquiry About GSoC 2025 Participation
by Eslam Samy 13 Feb '25

13 Feb '25

Dear Boost Community, I hope you’re all doing well. My name is Eslam, and I’m a student at Al-Azhar university in Cairo,Egypt, I have a strong interest in open source development. I’ve been programming in C and C++ for several years, primarily solving algorithmic challenges on platforms like Codeforces and LeetCode (2000+ problems solved), but I haven’t yet had the opportunity to contribute to large open-source projects. I recently joined this mailing list because I want to get involved in open-source development, and Boost is one of the most respected C++ projects out there. I would love to learn from this community and contribute in any way I can. I also wanted to ask: Does Boost plan to participate in Google Summer of Code (GSoC) this year? If so, I’d be very interested in learning about potential project ideas and how I can get started with contributions. Looking forward to hearing from you all and excited to be part of this community! Best regards, Eslam Samy GitHub: eslamsamy226 LinkedIn : https://www.linkedin.com/in/eslam-samy-097893220/

2 1

compilation time increased
by Murali Kishore 12 Feb '25

12 Feb '25

Hi, Observing compilation time increase when i include boost interprocess headers. is there a way to reduce compilation time as this time going more than hours in large project. -- Regards, Murali Kishore

4 4

asio::strand: Order of execution
by Georg Gast 11 Feb '25

11 Feb '25

Hi, If I use a asio::strand and post() there multiple function objects, are they executed in the same order or is the order of execution not specified? I think to use it as a work queue but I need them to be processed in sequence... Thx Georg

5 9

[review] [sqlite]
by Richard Hodges 04 Feb '25

04 Feb '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.

17 61

Decimal Review Result and Summary.
by John Maddock 02 Feb '25

02 Feb '25

First off I'd like to thank Matt and Chris for submitting the library for review, and for all the reviewers who submitted comments. My apologies for not posting this sooner, but this has been a difficult review to reach a definite result on. First the headline result: the result of the review is INDETERMINATE. What this means in practice: I'd like to encourage Matt and Chris to come back for a mini-review at a later date which should focus exclusively on the open issues listed below. I forget which library we applied this to in the past, but I believe the result is not without precedent. I note that a greater weight of reviews, and/or a clearer path forward may well have tipped the balance here. And of course as someone who's worked with Matt and Chris, I may well be being over-harsh in order to avoid bias... or perhaps I'm just over thinking the whole thing... In my notes below, I've split my comments into: * "Settled Issues", these were issues that were raised at some point but found not to be true issues. * "Todo", straightforward usability and implementation issues such as we get from any review process. I've filed matching GitHub issues for each of these. * "Open", these are the harder knotty problems, where it's not clear (yet) what the solution is. RATIONALE: we had five reviews (4 public, one direct to me), of which 4 were generally positive, and one was for reject. In addition, some of the positive reviews were directly contradictory in the direction they thought the library should progress in ("we should only support the fast types", vs "we should only support the fixed width types" etc). There were also some conditions for acceptance - mostly performance based - where it's not clear whether the objectives are possible in a sane time-frame. For example the often referenced Intel C library is frankly huge (source files > 6Mb in size) and makes heavy use of the "every function is a macro" C idiom, which at least for me renders the code virtually unreadable. As things stand I consider it unreasonable to ask the authors to replicate that work. In late breaking news, I also hear from Matt that GCC and IBM both "cheat" by using (mutually incompatible) non-IEEE binary encodings. There is also the "do we actually need decimal arithmetic" question - it is clear that many people think we do - there have been repeated attempts from researchers at IBM, Intel and others to push this towards standardization, in addition to some (rather patchy) hardware support. It's in C23, which means eventually C++ compiler support will be required too. Oh and python has a decimal library. However the authors need to articulate the case better - the killer application seems to be exact round tripping from human-readable and machine representations (ie exact representation of human data input). John Maddock (Decimal Library Review Manager) OPEN ISSUES ~~~~~~~~~~~ The case for decimal floating point needs to be better made - despite support from IBM and Intel, plus repeated standardization efforts, true killer examples seem to be thin on the ground. Perhaps liaison with other experts in the field would be helpful here (I note that Robert Klarer at IBM and also once around these parts has been involved in decimal proposals, https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1977.html)? Should arithmetic operations always be performed on the performance optimized forms? If so, perhaps storage optimized forms should have no operators (or their operators return the unpacked versions)? Review managers note: can we use DEC_EVAL_METHOD to set behavior here? How do we address the performance gap? Add the option to wrap the Intel library? Rewrite using the same methodology as Intel (this looks like a truly massive amount of work)? Several reviewers make this a condition of acceptance however. Should we use _fast integers or width specific ones? The answer appears to be platform specific. Perhaps it's a question of changing the correct instances of _fast integers rather than all of them? Should we abolish the _fast types and only provide fixed-width std compliant types: this is the forward looking option in line with what the standards are doing... but it directly contradicts the requests of some other reviewers. SETTLED ISSUES ~~~~~~~~~~~~~~ The decimal32 decimal64 names etc are reserved by various standards especially IEEE-754, we need to stick to those names. Over long literals are acceptable without warning or error, though a static warning facility would be nice. One reviewer suggests removing BOOST_DECIMAL_FAST_MATH, however as it performs similar optimizations to other libraries / compiler options, it looks reasonable to stay if the authors wish. One reviewer suggested shortening the namespace names - this is a tricky one, I see the issue, but we have a tradition (rightly or wrongly) for long_descriptive_names in boost. Plus there are always using declarations and/or namespace aliases. I will leave this to the authors to decide. long/int overloads of scalbln are fine by me as these are std mandated, however the reviewer makes a valid point that these are useful only on 16 bit platforms (I do note that the library is intended to be micro-controller compatible though, so this may well be an issue there). One reviewer suggests passing arguments by value is a mistake especially for 128 bit types, other reviewers refuted this. Other than some experimentation / double checking on windows and non-Intel platforms this does not appear to be an issue in practice. Suggest no change unless the double checks prove otherwise, a comment in the source or the design rationale may well be welcome. One reviewer suggested using CLZ in num_digits, but this has been checked and is slower (a comment in the source to that effect would be welcome. Note that std::lower_bound is not constexpr until C++26. REQUESTED CHANGES ~~~~~~~~~~~~~~~~~ Literals should be in their own namespace. https://github.com/cppalliance/decimal/issues/827 Allow implicit conversions for all conversions which do not lose precision: https://github.com/cppalliance/decimal/issues/828 Remove sprint support. https://github.com/cppalliance/decimal/issues/829 Split into "use what you need" smaller headers, in particular iostream and std lib support code should be in separate optional headers rather than in #ifdef blocks. https://github.com/cppalliance/decimal/issues/830 I'm also not convinced about the value added by the other cstdio functions, namely printf, fprintf and snprintf. They only support decimal arguments. This means that printf("Value for id=%s is %H", id, value) is an error if id is a const char*. Integers work because they are cast to decimal types, which I found surprising, too. Given an int i, printf("Value for %x is %H", i, value) works but doesn't apply the hex specifier. The integer is promoted to a decimal type, which is then printed. I'd have expected the latter to be a compile-time error. I'd say that this will be the case if you replace std::common_type by std::conjunction as Peter suggested. https://github.com/cppalliance/decimal/issues/831 Are concept names supposed to be public? If they are, please document them as regular entities. If they are not, please move them into the detail namespace. https://github.com/cppalliance/decimal/issues/832 Collected documentation improvements: https://github.com/cppalliance/decimal/issues/833 Do the exponent_type typedefs need to be public? Do they need to be 64 bit? I suspect the latter is all about extracting the bits from the representation, and the former is a convenience to avoid a long list of friends - although the list doesn't look *that* long? If they remain public then a comment in the source with rationale would suffice. https://github.com/cppalliance/decimal/issues/834 Can we add (possibly explicit) constexpr construction from string literal? https://github.com/cppalliance/decimal/issues/835 There is an undocumented public constructor: constexpr decimal32(bool coeff, T exp, bool sign = false) noexcept; which appears to be a mistaken addition? https://github.com/cppalliance/decimal/issues/836 I wonder if constexpr decimal32(T coeff, T2 exp, bool sign = false) noexcept; is under-constrained? The sign argument appears to be superfluous given that coeff can be negative, and we know up front the size of integer required to represent the coefficient and exponent so we might as well make this a non-template: smaller integer arguments will get promoted and larger arguments will quite correctly issue a warning (I wouldn't use a type smaller than int though, otherwise the things get altogether too picky): https://github.com/cppalliance/decimal/issues/837 There are a few places where pow10 is used with a constexpr argument, but while the function is constexpr it is not used in a constexpr context. The example picked up from the review was auto res_sig {(static_cast<unsigned_int128_type>(lhs_sig) * static_cast<unsigned_int128_type>(rhs_sig)) / pow10(static_cast<unsigned_int128_type>(13))}; in mul_impl.hpp but there may be others. https://github.com/cppalliance/decimal/issues/838 Consider using delegating constructors in for example constexpr decimal128::decimal128(bool coeff, T exp, bool sign) (if we keep this... but check for other opportunities). https://github.com/cppalliance/decimal/issues/839 Ensure that +0 and -0 are equivalent. https://github.com/cppalliance/decimal/issues/840 Make uint128 a non-detail type given that it is used in public interfaces. Such a shame that it can't be a real std::uint128_t, but perhaps a conversion operator could be provided when the type is available? https://github.com/cppalliance/decimal/issues/841 Rationalize traits class usage to make the code easier to read: https://github.com/cppalliance/decimal/issues/842 Code duplication: comparison operators calling into `equal_parts_impl()` for `decimal32_fast`, but the definition being placed directly into the comparison operator functions for `decimal64_fast` and decimal128_fast`. For me, this makes it seem like these 3 types must be implementing the comparison operators in different ways, when in reality they are doing exactly the same calculation, implemented in 3 separate places. https://github.com/cppalliance/decimal/issues/843 Code duplication with `bias_v`: https://github.com/cppalliance/decimal/issues/844 Explicit conversions need much better documentation for overflow behavior - I had to look at the source for to_integral to figure this out - I'm also wondering if returning zero on error is the right solution or if the result should be saturated? https://github.com/cppalliance/decimal/issues/845 Remove the footgun of lossy conversion from decimal floating point types. https://github.com/cppalliance/decimal/issues/846

6 9

Decimal: Formal review begins.
by John Maddock 31 Jan '25

31 Jan '25

The review of the proposed Decimal Number library by Matt Borland and Chris Kormanyos begins today and runs until 22nd Jan. You will find documentation here: https://cppalliance.org/decimal/decimal.html And the code repository is here: https://github.com/cppalliance/decimal/ Boost.Decimal is an implementation of IEEE 754 <https://standards.ieee.org/ieee/754/6210/> and ISO/IEC DTR 24733 <https://www.open-std.org/JTC1/SC22/WG21/docs/papers/2009/n2849.pdf> Decimal Floating Point numbers. The library is header-only, has no dependencies, and requires C++14. Please provide feedback on the following general topics: - 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? Do you already use it in industry? - 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? Ensure to explicitly include with your review: ACCEPT, REJECT, or CONDITIONAL ACCEPT (with acceptance conditions).header-only, has no dependencies, and requires C++14. Best, John Maddock (review manager).

18 94

Author assistance for WG21 display content
by Robert Beeston 30 Jan '25

30 Jan '25

Hello everyone, My name is Rob Beeston, and I’m the Product and Creative Director for C++ Alliance. I’m currently making arrangements for the upcoming WG21 event, and could use some help from some of the authors. We will be making posters, similar to this mockup ( https://downloads.cppalliance.org/images/boost-poster.png) to highlight the following libraries at the event: Hash2 Math Parser Scope Unordered Each poster would need a brief description, a longer explanation (perhaps 1-2 short paragraphs of what it does and/or how it works) and a code snippet that would best represent how to use it. Thanks and I’m looking forward to working with you. Rob

4 6

Interest for C++20 modules support of boost officially
by Chuanqi Xu 29 Jan '25

29 Jan '25

Hi Boost Developers, I am Chuanqi Xu, the maintainer for modules & serialization in clang and also a fan of C++20 modules. The post itself was motivated by a discussion (https://cpplang.slack.com/archives/C27KZLB0X/p1734335425348809 <https://cpplang.slack.com/archives/C27KZLB0X/p1734335425348809 >). You don’t need to read it if you’re not interested. I’ll try to make the post itself self contained. The original story comes from a high quality experiment for C++20 modules in boost (https://anarthal.github.io/cppblog/modules2 <https://anarthal.github.io/cppblog/modules2 >). The blog reads pretty good to me. However, anarthal (the author) told me later that the process of supporting modules in boost got suspended since the authors (or the maintainers) don’t want it since no one is going to use them. And if I want it, I need to send a mail here. Then this is the beginning of the story. First of first, I want to emphasize that “no one is going to use them” is not true. We’ve already used C++20 modules at larger scale internally for roughly a year. For boost (and other third party libraries), we choose to wrap a module ourselves as a workaround (with some compiler extensions to ease the refacotoring, but we don’t like it. We still want standard behavior). We didn’t reach out since we feel boost will support C++20 modules later or sooner so we don’t need to do anything specially. (Maybe we were wrong. We didn’t understand the ecosystem enough). Until yesterday, I just knew that boost didn’t know such needs. Before I wrote this email, I wondered a lot of words to emphasize that our need are a good example and the users of closed source are important users too. But just now, I searched the use of boost in modules in GitHub. I just realized I can show it (the importance of C++20 modules support for boost) much easily with the open source world. I searched `boost path:*.cppm` in GitHub and got the following list: https://github.com/infiniflow/infinity/blob/fa922afd58c973a9a317d2c09ad8cea… <https://github.com/infiniflow/infinity/blob/fa922afd58c973a9a317d2c09ad8cea… > https://github.com/ossia/score/blob/0ce6f62a97651a1248a92b3e13ce6ede10341d1… <https://github.com/ossia/score/blob/0ce6f62a97651a1248a92b3e13ce6ede10341d1… > https://github.com/RichardLuo0/make-dot-cpp/blob/e2ef10fd43060a2b56fc8f87f1… <https://github.com/RichardLuo0/make-dot-cpp/blob/e2ef10fd43060a2b56fc8f87f1… > https://github.com/slaakko/cmajor-mod/blob/32e6eb8dc099b395fa751340de96f478… <https://github.com/slaakko/cmajor-mod/blob/32e6eb8dc099b395fa751340de96f478… > https://github.com/df-com/dragonfly/blob/9dfcbc1153f292eb8581f1df7459600cc3… <https://github.com/df-com/dragonfly/blob/9dfcbc1153f292eb8581f1df7459600cc3… > https://github.com/nofe1248/Helium/blob/92ec4452b8c05e6d86c972f843196a4392a… <https://github.com/nofe1248/Helium/blob/92ec4452b8c05e6d86c972f843196a4392a… > https://github.com/LagrangeDev/liblagrange/blob/10e3b48f8d47fd65de00b14cfed… <https://github.com/LagrangeDev/liblagrange/blob/10e3b48f8d47fd65de00b14cfed… > https://github.com/yudaichen/feature-db/blob/e94ade969af682ed5dd25d70bf282b… <https://github.com/yudaichen/feature-db/blob/e94ade969af682ed5dd25d70bf282b… > This is not a complete list even for my search only and I believe there are other patterns to use boost with modules now (e.g., at least `*.cppm` is not the defacto suffix). And I also believe, from my experience as a C++ user, if boost provide modules, I may try to use it. But if boost didn’t provide it, maybe I won’t ask for it if I don’t want modules super bad. Since modules doesn’t add any new functionality actually. So most users may not ask for it explicitly. But if boost provides it, people may give it a try. The above text are the body of the post. I hope it can show it is needed. — Following of are some technical discussion for the extra maintainance burden by introducing modules. The conclusion is, I think, the burden is pretty low. Since modules are not complex to users. Different from other big features in C++, modules are pretty easy to understand. The complexity of modules are majorly on tools and the ecosystem. For programmers who don’t get involved to much to the ecosystem (or infrastructure), modules should be pretty easy to understand. For authors of libraries, after boost introduce modules, you only need to do 2 extra things: - In headers, add a macro (assume its name as BOOST_MODULE_EXPORT, which will be ‘export’ conditionally) to the entities that need to be exported. - In headers, include standard headers and other dependent headers conditionally so that we don’t include anything if the headers are in a module unit. e.g., https://github.com/boostorg/pfr/blob/f09e6aeae9d050897fff72b93d5f5e866cc5e1… <https://github.com/boostorg/pfr/blob/f09e6aeae9d050897fff72b93d5f5e866cc5e1… > then that’s roughly all you need for maintaining it at source level. For building and distributing related things, anarthal told me that the boost will handle it globally so the individual arthors don’t need to care about it. — In slack, there are some other discussion about module names and linking problems (https://cpplang.slack.com/archives/C27KZLB0X/p1734345716728609 <https://cpplang.slack.com/archives/C27KZLB0X/p1734345716728609 >). But I feel they are implementation details. I may not talk too much for that as a user at least now. And also there are opinions for configuration flags. These are the jobs of build systems (cmake is working on it). I think boost don’t need to worry for that. Similarly, at least libc++ has similar problems but libc++ still released std module. — Boost has a special position in the C++’s ecosystem. The most simple and impressive answer I’ve heard for the question “when can we start to use modules” is, “when boost makes it”. Thanks, Chuanqi

15 85

observing process blocked on find_or_construct
by Murali Kishore 28 Jan '25

28 Jan '25

Hi , We are trying interprocess scenario, one process created shared memory objects and killed and second process open the object using find_or_construct seeing this process blocked at getting lock. bt as shown below, #0 __lll_lock_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135 #1 0x00007fa6b6733eb6 in _L_lock_941 () from /lib64/libpthread.so.0 #2 0x00007fa6b6733daf in __GI___pthread_mutex_lock (mutex=mutex@entry=0x7fa6b198b070) at ../nptl/pthread_mutex_lock.c:113 #3 0x0000000001bc3822 in lock (this=0x7fa6b198b070) at /x86/include/boost/interprocess/sync/posix/recursive_mutex.hpp:90 #4 lock (this=0x7fa6b198b070) at /x86/include/boost/interprocess/sync/interprocess_recursive_mutex.hpp:163 #5 scoped_lock (m=..., this=<synthetic pointer>) at /x86/include/boost/interprocess/sync/scoped_lock.hpp:81 #6 boost::interprocess::segment_manager<char, boost::interprocess::rbtree_best_fit<boost::interprocess::mutex_family, boost::interprocess::offset_ptr<void, long, unsigned long, 0ul>, 0ul>, boost::interprocess::iset_index>::priv_generic_named_construct<char> (this=0x7fa6b198b010, type=<optimized out>, name=0x7ffde183ca20 "reported_slice_config_list", num=1, try2find=<optimized out>, dothrow=<optimized out>, table=..., index=..., is_intrusive=...) at /x86/include/boost/interprocess/segment_manager.hpp:1076 #7 0x0000000001bee007 in boost::interprocess::segment_manager<char, boost::interprocess::rbtree_best_fit<boost::interprocess::mutex_family, boost::interprocess::offset_ptr<void, long, unsigned long, 0ul>, 0ul>, boost::interprocess::iset_index>::priv_generic_construct (this=<optimized out>, name=name@entry=0x7ffde183ca20 "reported_slice_config_list", num=num@entry=1, try2find=try2find@entry=true, dothrow=dothrow@entry=true, table=...) at /x86/include/boost/interprocess/segment_manager.hpp:760 #8 0x0000000001bf112d in generic_construct<boost::container::map<unsigned int, gnb::broadcast_plmn_list, std::less<unsigned int>, boost::interprocess::allocator<std::pair<unsigned int const, gnb::broadcast_plmn_list>, boost::interprocess::segment_manager<char, boost::interprocess::rbtree_best_fit<boost::interprocess::mutex_family>, boost::interprocess::iset_index> > > > (table=..., dothrow=true, try2find=true, num=1, name=0x7ffde183ca20 "reported_slice_config_list", this=<optimized out>) at /x86/include/boost/interprocess/segment_manager.hpp:704 #9 operator()<std::less<unsigned int>, boost::interprocess::allocator<std::pair<unsigned int const, gnb::broadcast_plmn_list>, boost::interprocess::segment_manager<char, boost::interprocess::rbtree_best_fit<boost::interprocess::mutex_family, boost::interprocess::offset_ptr<void, long int, long unsigned int, 0ul>, 0ul>, boost::interprocess::iset_index> >&> (this=<optimized out>) at /x86/include/boost/interprocess/detail/named_proxy.hpp:132 please let me know in which cases this can be occured, we see first process also hangs in termination. -- Regards, Murali Kishore

3 3

End of Boost.Decimal Review
by John Maddock 25 Jan '25

25 Jan '25

The review of the proposed Decimal library has now ended - although given that there was a lot of lively discussion for me to sort through, there is still time to submit a late review if you wish. If I've counted correctly there were 5 reviews (4 on the list, one private): one firm reject and 4 conditional accept, plus many more people involved in the discussion than gave reviews. I have to be honest, I would have liked to have seen a couple more reviews in order to have reached a clearer consensus, so please bare with me while I sift through all the comments and try and reach a conclusion. My thanks to everyone who took part, and of course to Matt and Chris for submitting the library. Best, John.

1 0

GSoC 2025 Projects
by Matt Borland 24 Jan '25

24 Jan '25

All, In the modules thread and on Slack, I asked if Boost had a current plan for participation in GSoC 2025. I haven't received any responses yet, so I'll assume there isn't a plan. I'm wondering if anyone has: a) Projects they would like to propose for GSoC, and b) An interest in mentoring. Here are some ideas that I think could be beneficial and approachable: 1) A proof of concept for a Boost module, including distribution and installation processes, and potentially adding support to select libraries. This project could have easy access to the Clang and MSVC teams via their mentor it seems. 2) Bi-variate interpolation has been requested before in Math. ACM TOMS algorithms 751 and 761 could fit the bill, but their references are written in F77. A faithful translation and implementation of those papers would be a good start. 3) Chris Kormanyos and I are working on a cryptographic module that we intend to have certified under FIPS 140-3 and then propose to Boost. An extension of this could be a TLS project where a student provides a proof of concept with a generic file transfer server or similar that works securely with OpenSSL, and then also with our new module. I can mentor at least one of these projects. If anyone has past applications for the organization, please send a link or copies. We have until mid-Feb to apply as an organization, which I can do if no one else volunteers. Best, Matt

5 8

Another Boost.Decimal Review
by Jeff Garland 23 Jan '25

23 Jan '25

Thanks to Matt Borland and Chris Kormanyos for this good work. I vote to ACCEPT the library. I trust the authors to improve documentation, api, and performance as a matter of continued development. Let me say a few things about some discussions in the review threads up-front. *Standardization:* I'm an advocate for it and would be willing to help the authors with the process. Rationale: 1) this standardizes existing practice (aka IEEE 754), something like it is supported in many languages (specifically C23), and there's significant use cases for this in many domains even if it's slightly slower. 2) While a standalone library can go far, often a compiler/library can more easily optimize fundamental things like numeric types. 3) I spoke with Dietmar about the review and standardization -- he's still an advocate for having this capability, but has higher priorities at the moment. *N2849*: It's a decent design for 2009 -- less so in 2025. Specifically, w.r.t. conversion we should only perform automatic conversions from types (see below). The library already takes care of from_chars, format and some other more modern things N2849 wouldn't address. *C23 and _Decimal** Should this library consider being a layer over C23 types where that's possible? GCC supports them at least in a limited fashion. https://gcc.gnu.org/onlinedocs/gcc/Decimal-Float.html > Does this library bring real benefit to C++ developers for real world use-case? > Do you have an application for this library? Yes and yes. > Does the API match with current best practices? I have some quibbles here. *Construction*: template <typename T, typename T2>constexpr decimal32(T coeff, T2 exp, bool sign = false) noexcept; Is the sign flag helpful here? It seems simpler to just handle a negative coefficient -- like it already does. When I look at it there's already cognitive dissidence in my brain about if the sign flag *overrides* or *inverts* the coefficient sign. The N2849 api doesn't have this flag. *Fast Types:* I read through the list conversation about the _fast types. My suggestion is to drop them. Simplifies everything for users and implementers. The movement in c++ over the last decade(s) has been to precisely say the size of the type to ensure correctness and not 'let the platform decide' (aka uint32_t, int64_t, etc). In my comment on documentation you'll notice the c++20 extended floating point types *only provide* fixed sizes. Also N2849 and C23 don't support _fast types for decimal. *Conversions:* I'd like to see the library *pull back* on convertibility. long double ld{1.23456789234567}; decimal32 d(ld); // what happens -- round, truncate, doesn't compile? The best answer is doesn't compile. There's been significant work in the standard now to define floating point rank and limit conversions with the extended floating point types. Specifically: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p1467r9.html#rank There's also other work on type traits and value preserving conversions in the SIMD capabilities. Also, std::chrono basically already does this -- any value destroying conversion has to be explicit. At a minimum the answer needs to be better documented - aka does what 754-2008 says? For other examples of things I'd remove and make a free function cast/round -- aka explicit user decision: class decimal64 { ... explicit constexpr operator std::int8_t() const noexcept; This is highly likely to not be value preserving so shouldn't be possible without a decision on how to handle overflow. class decimal64 { ... explicit constexpr operator decimal32() const noexcept; *Literals* constexpr auto operator "" _DF(const char* str) -> decimal32constexpr auto operator "" _df(const char* str) -> decimal32 Why not _d32, _d64, _d128? _df makes me think fast, not 32. > Is the documentation helpful and clear? Not bad, but as usual improvements can be made. As a user I'm going to need to select one of these types -- I'd love to see a table like this one at cppreference for named floating point types: *Type name* Defined in header <stdfloat> <https://en.cppreference.com/w/cpp/header/stdfloat> Literal suffix Predefined macro C language type Type properties bits of storage bits of precision bits of exponent max exponent std::float16_t f16 or F16 __STDCPP_FLOAT16_T__ _Float16 16 11 5 15 std::float32_t f32 or F32 __STDCPP_FLOAT32_T__ _Float32 32 24 8 127 std::float64_t f64 or F64 __STDCPP_FLOAT64_T__ _Float64 64 53 11 1023 std::float128_t f128 or F128 __STDCPP_FLOAT128_T__ _Float128 128 113 15 16383 std::bfloat16_t bf16 or BF16 __STDCPP_BFLOAT16_T__ (N/A) 16 8 8 127 Not sure how it renders in email so source: https://en.cppreference.com/w/cpp/types/floating-point Not looking for exact replication, but something like this. In the *using the library* section I'd like to see some: - examples of using it it math - examples of the behavior of NAN/inf values - conversions from other types like float expanded Where is the design decisions section? Some of the things I'm asking about should be covered in the docs. > Did you try to use it? What problems or surprises did you encounter? I didn't have time to play with it unfortunately -- godbolt would be helpful. That's all for now. Jeff

4 5

Re: [boost] Decimal: Formal review begins
by Glen Fernandes 23 Jan '25

23 Jan '25

I mentioned this to Matt, but I would like to see benchmarks comparing boost::decimal64_fast to a Decimal64 backed by Intel's DFP library, which is what I know to be in actual use today: https://www.intel.com/content/www/us/en/developer/articles/tool/intel-decim… Not that the benchmarks comparing to GCC's Decimal64 (which is based on the libbid which ships with libgcc) aren't useful, I personally don't know anyone using that today. Benchmarks should ideally also include Intel's compiler, because at least one of the relevant parties who motivated me to suggest the Decimal64 library (to Vinnie as a potential project) do use the Intel C++ compiler (and their Fortran compiler) for areas where they perform better. (The non-fast versions don't matter to me. I don't know anyone who would want to use them). Glen

12 36

Decimal Library: Last call for reviews?
by John Maddock 22 Jan '25

22 Jan '25

Formally, today is the last day of the Decimal Library review, so far there has been a lot of discussion, but only three full reviews with outcomes. Are there any more reviews incoming? Thanks, John.

1 0

My review of Decimal
by Ivan Matek 21 Jan '25

21 Jan '25

Hi everybody, PDF size exceeds ML limit so here is google drive link https://drive.google.com/file/d/1kH9WkeTDxN7FFqM_g7hV_-e3kJPlTGBr/view

6 16

Reminder to submit Boost.Decimal reviews
by John Maddock 20 Jan '25

20 Jan '25

Just a gentle reminder that the Decimal library review is currently ongoing, there's been plenty of discussion, but only one full review so far.... so if you're thinking of submitting a review, now would be the time ;) Thanks all, John.

1 0

Fw: Boost accepted in Google Summer of Code 2021
by Christopher Kormanyos 17 Jan '25

17 Jan '25

----- Forwarded Message ----- From: "boost-users-owner(a)lists.boost.org" <boost-users-owner(a)lists.boost.org>To: "e_float(a)yahoo.com" <e_float(a)yahoo.com>Sent: Wednesday, March 10, 2021 at 07:51:24 PM GMT+1Subject: Re: [boost] Boost accepted in Google Summer of Code 2021 To post messages to the Boost Users mailing list, you will need to subscribe this e-mail address via the Boost mailing list web page at: http://lists.boost.org/mailman/listinfo.cgi/boost-users You will need to take this step even if you intend to post only through GMane or some other news gateway. In this case, you may wish to edit your subscription options to turn off mail delivery. >> We're in again! > Thank you, David! Hi Matt (@mborland) This was, as far as i recall, our last successful timegetting into and finishing some GSoC 2021 projects. We had that whole Corona thing going on and it wasa tough time for everyone. As far as applying as an org, maybe David hassome old material. - Chris_________________________________________Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

2 2

Adding logical implication to boost
by Ivan Matek 09 Jan '25

09 Jan '25

Hi everyone, there has been a recent proposal to add logical implication to C++ as an operator. github tracking issue <https://github.com/cplusplus/papers/issues/1641> P2971R2 <https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p2971r2.pdf> For a video description you can see this talk <https://youtu.be/bgyY3x8y4PE?feature=shared&t=1470> by Walter(it is only few minutes, not entire talk). While I agree with concerns mentioned on the issue, i.e. using a *precious *token => on rarely used functionality I do think that implementing a simple function helper is reasonable. Poll in issue shows that this is also likely standardization future. POLL: We agree with adding a function object logical_implication (tentative name, akin logical_and, `logical_or’). SF F N A SA 9 12 3 0 0 As for if it is worthwhile to add this simple logic to boost instead of people just writing their own I will just say I would prefer to have something named in boost instead of people reinventing same thing many times in their projects. I have used it few times in my career, so quite rarely, but again that means I have used it much more often than 80+% of algorithms in <algorithm> header. As for location I presume best place would be Boost.Algorithm although you could say that Boost.Core can be a candidate because it is a basic operation and would benefit from shorter namespace. I would be still inclined against this since I have seen core/util/common become huge in many codebases I have worked in. I have tried to check if this already exists in Boost; all I found was an example in Boost.Hana.

6 7

Forthcoming Decimal Library review (15th Jan)
by John Maddock 08 Jan '25

08 Jan '25

Just a gentle reminder that the review of the decimal number library by Matt Borland and Chris Kormanyos will start NEXT WEDNESDAY 15th Jan. The library is an implementation of IEEE 754 Decimal Floating Point Numbers. Documentation: https://cppalliance.org/decimal/decimal.html Code: https://github.com/cppalliance/decimal/ Motivation: Current C++ floating point types store the significand (often incorrectly referred to as the mantissa) as binary digits. Famously this leads to representation errors: https://0.30000000000000004.com <https://0.30000000000000004.com>. Decimal floating point numbers avoid this issue by storing the significand in base-10 (decimal). The other major difference between binary and decimal floating point types is that the latter allows for multiple representations of the same number. For example 1e5 could also be stored as 0.1e6, 0.01e7, so on and so forth. These are referred to as cohorts which binary does not have as there is only one way to represent each number in binary floating point. Use Cases: The use case for Decimal Floating Point numbers is where rounding errors are significantly impactful such as finance. In applications where integer or fixed-point arithmetic are used to combat this issue Decimal Floating Point numbers can provide a significantly greater range of values. For example, while a fixed-point representation that allocates 8 decimal digits and 2 decimal places can represent the numbers 123456.78, 8765.43, 123.00, and so on, a floating-point representation with 8 decimal digits could also represent 1.2345678, 1234567.8, 0.000012345678, 12345678000000000, and so on. I believe Matt has some minor doc updates to push between now and next week, but other than that the library is good to review (but hold your fire until we start next week unless you're away etc). Best, John.

1 0

Invalid sha256 for boost_1_87_0.tar.bz2 archive
by Samuel DEBIONNE 07 Jan '25

07 Jan '25

Dear all, In the conda forge CI (that builds the boost packages), I noticed that some jobs are failing due to a difference between the advertised and computed sha256 checksum. The json file at https://archives.boost.io/release/1.87.0/source/boost_1_87_0.tar.bz2.json has af57be25cb4c4f4b413ed692fe378affb4352ea50fbe294a11ef548f4d527d89 While sha256sum of https://boostorg.jfrog.io/artifactory/main/release/1.87.0/source/boost_1_87… gives 79e6d3f986444e5a80afbeccdaf2d1c1cf964baa8d766d20859d653a16c39848 Has the archive been updated and not the sidecar json file? Thank you, Samuel

2 2

Your Boost Talk at CppCon?
by Vinnie Falco 02 Jan '25

02 Jan '25

Hi everyone. I think it would be nice to have several talks about Boost for the 2025 CppCon program. We need volunteers who are able to attend and give a talk. If you are interested please email me at vinnie.falco(a)gmail.com to indicate your intent and propose a subject for the talk. There are some resources available to help volunteers get their abstract prepared for submission, to improve the quality of the proposal, ensuring a greater likelihood of the talk being accepted. Getting a Boost talk accepted has been hit or miss in recent years and I would like to change that. If we can get enough volunteers involved much earlier in the process (say, this month) then we have time to assemble a strong "Boost track" with high quality abstracts. This can incentivize the conference to make Boost talks an enduring feature of its programs going forward. If you have questions or comments about Boost talks at CppCon or other conferences, a discussion here is also welcomed. Thanks!

1 0

Re: [boost] announcing boost.async
by microcai 01 Jan '25

01 Jan '25

Klemens Morgenstern via Boost <boost(a)lists.boost.org> 于2023年3月17日周五 23:22写道： > Hi, > > I've been working on a C++20 coroutine library, called `async`, > which is meant to be for C++ what asyncio is for python or generic > async/await is for javascript. > It's meant to be a framework for single threaded coroutine applications. > > It provides coroutine types, such as promises, tasks and generators to > generators are useless for real word coroutine usage. > model async operations, > channels for inter-coroutine communication and functions > like select, gather & join to wait or combine multiple awaitables. > > It's asio-based, i.e. uses asio::io_context as its event-loop and can > co_await any asio operation. > > As this is a very complex domain, I really would be happy to have some > users. > This will help me to improve documentation & come up with more > example ideas. > > Docs: https://klemens.dev/async > Repo: https://github.com/klemens-morgenstern/async > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost >

2 1

[boost.context] questions about Lazy Float Point State Preservation
by microcai 01 Jan '25

01 Jan '25

Does jum_fcontext do lazy state preservation on FPU? most of the time, coroutine is executing async IO code rather than cpu intensive code. Mostly, IO code does not use floating point. but no preserving FPU state is error prone. Does fcontext employ "lazy state preservation on fpu registers"?

1 0

Adding optional<T&> find like method to associative containers in boost.
by Ivan Matek 28 Dec '24

28 Dec '24

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 80

Formal review request for Hash2
by Peter Dimov 23 Dec '24

23 Dec '24

I'd like to request a formal review for the Hash2 library https://github.com/pdimov/hash2 https://pdimov.github.io/hash2/ (by Christian Mazakas and myself.) The library implements an extensible framework for implementing hashing algorithms that can support user-defined types. Its structure is largely based on the paper "Types don’t know #" by Howard Hinnant, Vinnie Falco and John Bytheway. https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3980.html We're looking for a review manager. Comments and questions are welcome; you don't need to wait for the review.

14 75

[hash2] Review Report
by Matt Borland 21 Dec '24

21 Dec '24

Dear all, Again, thank you to those who participated in the review of `Hash2` by Peter Dimov and Christian Mazakas from 7 to 15 December 2024. Bottom line up front: The library is ACCEPTED. By and large, the discussion around the library was positive, with reviewers appreciating that it implements the "Types don't know #" proposal. I think some discussion was perhaps too narrowly focused on providing hash algorithms, as that is not the over-arching goal of the library. Below is a summary of the main discussion points and recommendations from both reviewers and me. Discussion and Recommendations: 1) Support for `std::span`. Based on the discussion, it seems like the use of `std::span` has moved from theoretical to being quite popular. Adding an API for span would in principle be OK behind the requisite feature test macros, but it will add to the conceptual requirements which I'm not convinced is beneficial. Unless Peter and Christian intend to move to C++20, and they don't, I think it would be unreasonable at this time to require spans behind macros in the implementation to allow warning-free builds with Clang's `-Wunsafe-buffer-usage` and whatever memory safety profiles turn out to be. If this library was targeting C++20, or intended to be certified by a standards organization, this would be an entirely different conversation. 2) C++ language standard requirement. As I kind of expected, there was limited support for keeping the library at C++11. The authors should feel free to use C++14 and drop support for any non-conforming compilers before initial release. 3) Documentation. Peter Turcan provided a great deal of feedback on the documentation which I expect the authors to handle. There were also quite a few calls to re-arrange the documentation to put working examples and pitfalls discussed during review first, and details of concepts later. The single vs. multi-page documentation debate will never have a clear winner, so I defer to doc writer's preference on that one. The authors have a pretty good sense of the edits they need to make, so I won't belabor the point. 4) Security. Secure construction was included in the conditional acceptance criteria of two reviews - for example, default construction and allowing too-short keys in SipHash were considered harmful. There were also concerns that the algorithms provided would be considered cryptographically secure. Since the library does not intend to be a cryptographic provider (as that is not the real point of the library), I think an annotation at the top of the docs stating as much should be added. 5) Relationship to `ContainerHash`. Several reviewers noted that since there is no explicit Hash1, the relationship with `ContainerHash` should be explained. Peter currently maintains `ContainerHash`, so I think it would be useful to add similar documentation there as well. This could help avoid the situation we have now where `MP11` fully replaces the functionality of `MPL`, but that's not obvious to the casual outside observer. 6) The concept of HashAlgorithm. There was much discussion around the concept of HashAlgorithm and how it deviates from existing practice. If Peter and Christian don't want to be the sole providers of hash algorithms for their library, they need to provide: - A way to use existing implementations and/or examples in the documentation (this was part of the acceptance criteria for all but one conditional acceptance). This can be accomplished by adding Guidance and an example of an adapter. - An FAQ section addressing questions like "Why does the library impose additional requirements such as result extension on hash algorithms which go beyond the cryptographic specifications in corresponding RFCs?" Boost.Multiprecision already implements this approach to allow unknown arithmetic backends to be used. Final Verdict: I ACCEPT the library. The library was clearly well designed, and the authors provided clear justification for implementation decisions when questioned (e.g., `tag_invoke` for functions as customization points). Peter and Christian are both responsive enough that I expect they will address the above list without needing the forcing function of a conditional accept followed by a review in the future to ensure completeness. In fact Christian already showed me a draft of an OpenSSL adaptor. If this library was coming from an outsider, my opinion would be different. For transparency the final tally of reviews received was ACCEPT: 9, REJECT: 3, CONDITIONAL ACCEPT: 5. Thanks again to all that participated and congratulations to Peter and Christian. Happy Holidays, Matt

3 2

Query on std::variant support
by Murali Kishore 20 Dec '24

20 Dec '24

Hi, Want to check is std::variant allocating memory from shared memory using boost interprocess allocators. EX: std::variant<int, float> v, w; // Define types A and B that we will store in the variant struct A { int x; A(int val) : x(val) {} }; struct B { std::string str; B(const std::string& s) : str(s) {} }; // Define the variant type using MyVariant = std::variant<A, B>; guide me for the above examples to create custom allocators. -- Regards, Murali Kishore

2 1

Re: [boost] Interest for C++20 modules support of boost officially
by Ruben Perez 19 Dec '24

19 Dec '24

On Thu, 19 Dec 2024, 15:44 John Maddock, <jz.maddock(a)googlemail.com> wrote: > > > If I understood the CMake developers and Chuanqi correctly (please let > > me know if I didn't), you do install a library with the generated > > object files, but you do not install the BMIs, as they're like > > pre-compiled headers. > > > > Let me explain how I understood it with two concrete examples. Take > > Boost.Url as an example of a compiled library, and Boost.Regex as an > > example of a header-only library. > > > > 1. Boost.Url today installs: > > * libboost_url.a, containing function definitions. > > * Headers, containing declarations. > > 2. Boost.Url in the module world would install: > > * libboost_url.a, containing the same function definitions as above. > > * A boost_url.cppm file, akin to what headers are today. > > CMake would build a BMI from this file when a user needs to > > import boost.url. > > In practice, this cppm file will likely be implemented in terms of > the > > header files that we have today. > > 3. Boost.Regex today installs: > > * Headers, containing declarations and definitions. > > 4. Boost.Regex in the module world would install: > > * A libboost_regex.a object, containing module initializers [1]. > > For instance, if you have a singleton defining a Boost.System > > error category, > > initialization code for the singleton would be emitted here. > > From the docs, it seems this object gets created even if no > > initialization code is required. > > * A boost_regex.cppm file, containing the bulk of the library, akin to > > what we provide using headers today. > > > > My intention is doing some testing to see how much trouble would this > > new libboost_regex.a library cause. > > I'm not quite convinced it's that simple, at it's most basic, consider > an inline function that is part of the module interface, if I compile > the module's object library for release, and then do a debug build of > the bmi and my project what happens? Even if clang makes that example > work out in msvc land where almost every option creates binary > compatibility issues, I see users compiling the object library from > source on a per-project basis. > I'd expect the inline function to be part of the BMI (which gets built by the user), and not part of the object file, thus not creating trouble. Of course, I could be wrong, so I'll try it. Regards, Ruben.

1 0

Boost 1.87.0 Release Report
by Vinnie Falco 17 Dec '24

17 Dec '24

We are proud to publish the first Boost Release Report, for 1.87.0. This report is designed to showcase and credit the work of the many volunteers who contribute to the libraries and other things in Boost, published as an official release three times a year. https://downloads.cppalliance.org/reports/boost_1_87_0_release_report.pdf Thanks

4 8

[hash2] Review of Hash2
by Antony Polukhin 16 Dec '24

16 Dec '24

> - What is your evaluation of the design? The design is good, but there is a major issue with security/safety in default constructors of the hash algorithms. ## HashDOS issue The issue is related to HashDOS attacks. The default seed must not be 0. Because with 0 the attacker could easily find strings of the same size that result in the same trailing bits of the hash result. As a result on those strings all the operations with unordered containers degrade to O(N) for each string, giving O(N*N) complexity for a set of strings. The issue affects any parsing where the result is stored into an unordered container: HTTP headers, HTTP cookies, JSON keys, XML... Our in-house experiments show that a single laptop can easily put down a few hundreds of servers just by sending the same precomputed HTTP request. The servers start to use 100% CPU and do not respond to other requests. The problem is so critical, that for some time we write HasDOS tests to make sure that our data structures are not affected: https://github.com/userver-framework/userver/blob/develop/universal/src/htt… With some math knowledge the attack becomes even more simple see https://orlp.net/blog/breaking-hash-functions/ Quick fix for the HashDOS is to generate a random number at the program start use it to initialize all the hashes on construction. Is still leaves a theoretical possibility of attack if there's only one instance of the application or the attacker generates strings set for each instance and sends them in one go. We were not patient enough to generate the exploit, which does not actually mean that it is not possible. A more mature fix is to generate a random seed for each request or container. We were using that approach for quite some time https://github.com/userver-framework/userver/blob/d09b427b42fc80dcd66b8161d… . We also checked some other popular frameworks for the HasDOS issue. Too many of them were affected (we reported to the authors, but not all of them reacted to the problem). All of the above leads to the following conclusion: developers are not aware of that critical issue or do not take the issue seriously. To not provoke vulnerabilities the hashing must be safe by default. ## tag_invoke is dreadful tag_invoke is over complicated. It may make sense if there is a need to specialize the behavior not just for the user defined type, but also to specialize behavior of the user defined type depending on the hashing algorithm and/or flavor. Such functionality does not seem to be required here. So instead of ``` template<class Hash, class Flavor> friend void tag_invoke( boost::hash2::hash_append_tag const&, Hash& h, Flavor const& f, X const& v ) { boost::hash2::hash_append(h, f, v.a); boost::hash2::hash_append(h, f, v.b); } ``` how about using a simpler approach: ``` template<class Visitor> friend constexpr void hash_visit(Visitor visitor, X const& v) { visitor(v.a); visitor(v.b); } ``` where Visitor could be ``` [&h, f](const auto& value) { boost::hash2::hash_append(h, f, value); } ``` ## std::hash and hash_value I'd appreciate functionality to reuse boost::hash2 functionality with std::hash and hash_value. It would be ideal to have something like: ``` template <class T> requires boost::hash2::supports_v<T> struct std::hash { std::size_t operator()(const T& x) const { boost::hash2::default_hasher h{boost::hash2::on_program_start_seed}; boost::hash2::hash_append(h, {}, x); return boost::hash2::get_integral_result<std::size_t>( h.result() ); } } template <class T> requires boost::hash2::supports_v<T> std::size_t hash_value(const T& x) { // put into Boost.Hash return std::hash<T>{}(x); } ``` So that the user just needs to provide boost::hash2 customization for its type, and after that it works with the standard library hashing and old boost hash. > - What is your evaluation of the implementation? Very good. > - What is your evaluation of the documentation? Good. > - What is your evaluation of the potential usefulness of the library? Do you already use it in industry? Not used it. The library is very useful because it researches the constexpr hashing, proposes hash combining and attempts to solve the other std::hash issues. > - Did you try to use the library? With which compiler(s)? Did you have any problems? Not used it. > - How much effort did you put into your evaluation? A quick reading of sources and docs. > - Are you knowledgeable about the problem domain? Yes, but not an expert. > Ensure to explicitly include with your review: ACCEPT, REJECT, or CONDITIONAL ACCEPT (with acceptance conditions). CONDITIONAL ACCEPT. The behavior of the default constructor must be secure. `tag_invoke` seems to be an overkill.

4 5

[hash2] Formal Review Begins
by Matt Borland 16 Dec '24

16 Dec '24

Dear all, The review of Hash2 by Peter Dimov and Christian Mazakas begins today Saturday, December 7th through Sunday December 15th, 2024. Code: https://github.com/pdimov/hash2 Docs: https://pdimov.github.io/hash2/ Please provide feedback on the following general topics: - 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? Do you already use it in industry? - 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? Ensure to explicitly include with your review: ACCEPT, REJECT, or CONDITIONAL ACCEPT (with acceptance conditions). There's already been a flurry of conversation so I thank you all for that. If you have any questions during this process feel free to reach out to me. Additionally, if you would like to submit your review privately, which I will anonymize for the review report, you may send it directly to me at: matt(a)mattborland.com. Matt Borland Review Manager and C++Alliance Staff Engineer

20 94

[hash2] Review
by Julien Blanc 13 Dec '24

13 Dec '24

his is my review of the proposed boost::hash2 library # What is your evaluation of the design? The base idea, separating the hash algorithm from the actual hashing of objects, is a brilliant one. The library consist on two parts: * a collection of hashing algorithm, some of them of crypto quality * a c++ objects hashing facility Given this design, i would not have expected from the library to provide a thorough collection of hash algorithm. But it's a good think to get them. I would have expected, however, to see some guidance about how to integrate an external hashing library. Actually it is unfortunate that this part is missing, because it seems a lot more harder than it should be. Several design decisions could be improved in my opinion: * the requirements on the HashAlgorithm concept are too strict, and have no rationale in the documentation * copy constructibility and copy assignment are unusual across current hash implementations, as it has been noted by other reviewers. I can understand a rationale for copy construct, copy assignment looks very weird to me. The only rationale i can think of is resetting the internal state to a defaulted state, which could be a specific operation. * creation with seed (either as uint64 or as an array) as well as default construction is required. It seems odd. The documentation, for example, strongly advice agains using siphash without a seed. I would prefer that it is a compile time error to use siphash without a seed / with an incorrectly sized seed. I've no problem adding a key/seed to algorithms that do not mandate them, though. But, since the library itself does not create the HashAlgorithm themselve (there is one notable exception to that that), it should not put additional requirements beyond what it uses. The HashAlgorithm concept could be: struct HashAlgorithm { using result_type = /*integral or array-like*/; static constexpr int block_size = /*...*/; // optional void update( void const* data, std::size_t n ); result_type result(); }; Interestingly enough, most of object hashing works if you provide it with such an algorithm (not copyable and not default constructible). I failed to see where default construction is used outside tests, for example. * the usage of void const* + size in interface is controversial, as several people would prefer a span<>. There are good reasons for not using span, and this is not something that should be an issue, as this should only impact HashAlgorithm writers. It is in my opinion an unfortunate design choice that this internal interface is leaked to the end user. The functionality is already provided by hash_append_range, which could be the advertised way of hashing bytes via that library (ie, when mixing hashing of object and hashing of bytes, eg when implementing custom hashing for a type). * constexpr use mandates usage of unsigned char const*. So it could be the primary supported interface over void const*, to avoid interface duplication. * the requirement on result extension is also uncommon. While i understand the rationale, it should be noted that it is likely to cause some language interoperability issues, as it is not necessarily specified by the algorithm. Implementations in other languages are unlikely to provide them, making the feature a niche one, unless the underlying algorithm specification provides it. * most of the functionality is provided by the hash_append function, and the hash_append_xxx helpers. This is a neat design. * The Flavor template argument allows to customize hashing of objects, to get platform-independants hashes. This is a good idea, but it comes with some problems: * the flavor is repeated over each hash_append call. I don't think it is a realistic use case that the flavor changes over time. If i were to integrate the library in our code base, the first thing i'll do is write a wrapper to get rid of that flavor argument at every call site. * the default flavor uses std::uint64_t for size. It seems odd. If i'm not asking for a specific flavor, i'm not asking the hash to be consistent accross different systems. So std::size_t should be used there instead. This looked to me like a pay for what you don't use situation, so i ran a quick near worst-case benchmark on our arm platform (hashing a million times a std::vector of the three integers 1-2-3), to find out that it makes a the code using size_t runs 15% faster. # What is your evaluation of the implementation? The implementation looks good. Code is clean, very readable. A minor remark in hash_append_unordered_range : m should be declared as std::size_t (or std::uint64_t). The current typename std::iterator_traits<It>::difference_type m = 0; is wrong. I'm not at ease with hash_append_unordered_range. The fact that it reduces the hash to 64 bits, simply making a sum of the element hashes, and then hashing that, does not look right. If the goal is simply to avoid unintended collisions, it's probably fine. If the goal is to preserve against an attacker mindfully trying to provoke collisions, it may do the trick,although intuitively xoring the whole results would be better at that job than summing truncated results. If it's to preserve cryptographic properties of the hash function, then it looks wrong. Another remark is about size serialization. The library relies on std::tuple_size to identify container-like structs, but not include the size in the hash (or is it because of is_contiguously_hashable?). This leads to unintuitive results, such as: std::array<int, 4> a{1,2,3,4}; std::span<int, 4> s(a); Hash h1,h2,h3,h4; hash_append(h1, {}, a); hash_append_range(h2, {}, begin(a), end(a)); assert(h1.result() == h2.result()); // TRUE hash_append(h3, {}, s); hash_append_range(h4, {}, begin(s), end(s)); assert(h3.result() == h4.result()); // FAILS I'm not sure there's a general solution to this issue, though. But since std::array models a container, not including its size in the digest may not be the wisest choice (the doc talks about plain arrays, not about std::array, so i don't know if it's a bug or a feature) # What is your evaluation of the documentation? The order of the documentation is odd. I would expect it to first explain me how i use the library with the provided algorithm to hash c++ data or bytes, but it first goes into deep details about how for example how result() can be called multiple times, or what requirements are set on custom hash algorithms. A description of the scope of the library would be welcomed. It both provides hashing for use by containers, and cryptographic quality hashing. These two seems at first unrelated, and the library lies in a not clearly defined in-between. It has been explain during the review, and the arguments given are convincing, and should find their place in the documentation. The motivation for machine architecture independant hashes is lacking. Usually, the way to achieve this is to use a domain specific canonical form, because endianness or word size is unlikely to be the only variable at stake here. But overall, the documentation has all the relevant information. A tutorial / quick start would be a nice addition. I dislike the "single page style" documentation, and hope the tooling can be improved in this regard. # What is your evaluation of the potential usefulness of the library? Do you already use it in industry? I have a need for an easy to use sha1, that i can easily compile for embedded targets. Having that in boost actually lowers the number of external dependancies, so yes this is definitely useful. I currently don't have a need for the object hashing facility, but would definitely use the library it if the needs arise. # Did you try to use the library? With which compiler(s)? Did you have any problems? I tried with several flavors of gcc, cross-compiling for bare-metal cortex-m0 targets or embedded arm32 linux, as well as standard debian x64. Everything worked. # How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? I did not review the algorithm implementations. I spent around 15 hours on studying the library doc and internals. # Are you knowledgeable about the problem domain? No specific knowledge of the domain. # What is your final recommendation I would recommend to CONDITIONALLY ACCEPT the library into boost, the conditions being: * demonstrate the usage of an existing external hash library into the boost::hash2 framework * remove default construction and too short key construction for algorithms where this is actually harmful (such as siphash). I don't have an issue with providing constructors with keys for algorithms that do not mandate it. But boost code should encourage correct usage of the algorithms it propose, not allow bad usage in the name of genericity. The following improvements should imho be done, but i don't base my conditional acceptance on them. Actually some of them can be done on top of the proposed library: * advertise hash_append_range as the recommended way to add untyped data to the hash algorithm (or define an additional hash_append_bytes to fulfill this role). * adds a tutorial / introduction in the doc, move the whole hashing byte sequences item after the hashing c++ objects item (if previous point is adressed, part of it would have to be included in the hashing c++ objects item). * makes copy construction requirement on hash algorithm a requirement only if hash_append_unordered_range is used. Hashing unordeder ranges is an open problem, some creative other solutions may be found, and i see no reasons why they would involve duplicating the algorithm state. Actually, if the hash is default constructible, then it is not needed. You need either one of default or copy constructible, not both. * use std::size_t instead of std::uint64_t for the default_flavor, as this is faster on some platforms. * provide wrappers that avoid repeating the flavor over and over. It is much more convenient for the user to write once using MyHash = hash2::FlavoredHash<hash2::default_flavor> and then MyHash::append(X) than repeating over and over the parameter. Finally, i want to thank Peter for developing and proposing this library for boost, and Matt for managing the review. Regards, Julien

3 3

Ruben's Hash2 review
by Ruben Perez 13 Dec '24

13 Dec '24

Hi all, This is my review of the proposed Boost.Hash2. Thanks Peter and Chris for submitting the library, and Matt for managing the review. - What is your evaluation of the design? Very good. This is how hashing C++ objects should work, as it properly separates concerns between types and hash functions. I think usability could be improved if the template class hash shown as an example was included as part of the library and introduced much earlier in the documentation. In general, the HashAlgorithm concept makes sense. I'm not convinced about the HashAlgorithm::result() interface, for two reasons: * It makes integration of third-party hashes more difficult, as already noted by other reviewers. * The naming suggests an accessor, rather than a modifier. I'd consider splitting it into two functions, maybe finalize_block() and result(). But I can also see the benefits of the approach taken. I miss some higher-level features when working with untyped byte sequences. While this doesn't seem the main value proposition of the library, it's listed as a valid use case. See below for more info. These are nice-to-haves rather than requirements, though. I was initially surprised to find out that the library was header-only, as I didn't know that compile-time hashing was something worth it. I was initially worried about compile-times. I built one of the examples with compile-time profiling (-ftime-trace) and the library is pretty lightweight, so I have no problems with the header-only design. Have you considered somehow supporting hashing for objects describable via Boost.Pfr? I had it requested by some users in MySQL even when I had built-in Boost.Describe support, so it may get requested here, too. - What is your evaluation of the implementation? The parts where I've peaked in are good. Some comments would have helped me, but in general I've been able to follow. The test suite looks pretty comprehensive, too. Some fuzz tests for the cryptographic algorithms would be appreciated (I can help if required). As other reviewers have commented, the algorithm for hashing unordered ranges can use some improvements to make it more secure. I'm no security expert and can't judge how important this is, but I'm pretty sure the author will solve this promptly. The implementation of cryptographic functions is currently slower than solutions like OpenSSL [4], but the author has manifested the possibility of closing this gap. It would be nice having HashAlgorithm modelled as a C++20 concept, although the required macro machinery required to perform the checking only if concepts are supported (like BOOST_ASIO_COMPLETION_TOKEN_FOR does) may be too much effort for the benefit it brings. Regarding Boost integration, a build.jam should likely be added, so the library integrates in the new modular Boost infrastructure (although I've been able to use the library fine without it). This can be done after acceptance. As a matter of curiosity: which compilers do not support __builtin_is_constant_evaluated? (as they will always get the slow memcpy implementation, even at runtime). - What is your evaluation of the documentation? The documentation is good, and explains rationales pretty well, but the order could be improved: * Most users will likely want to use the existing algorithms with their unordered containers, so this should be explained first. * The next block of users will likely want to use the existing cryptographic hash algorithms to untyped byte sequences, so this should be next. * The rest can be left as is. I miss the motivation for the flavor construct in the docs. If I understood correctly, it's only relevant if you plan to somehow serialize your hashes. Maybe an example could help. The library is also suitable for use cases that combine the C++ object hashing and untyped byte sequence hashing parts, as explained by the author here: https://lists.boost.org/Archives/boost/2024/12/258765.php. Such cases are the rationale behind having cryptographic functions within the same umbrella as non-cryptographic ones. I'd suggest adding these to the docs. In general, I dislike single-page docs (which unfortunately seem pretty popular in Boost), as they're difficult to search. I also miss linking (e.g. hash_append should contain a link to its description in the reference). It would also be beneficial to explain the library's relationship with boost::hash / Boost.ContainerHash. In general, making it more approachable for non-expert users would be good. - What is your evaluation of the potential usefulness of the library? Do you already use it in industry? Robust, extensible C++ object hashing is very useful. My immediate use case is related to hashing untyped byte sequences, though. MySQL/MariaDB authentication involve a challenge-response protocol that involves hashing the user-supplied password with a server-supplied challenge, using either SHA1 (sigh) or SHA256 [1]. I'm currently using OpenSSL, as I use it for TLS, too. This library would allow me to make the OpenSSL dependency optional (which I've been requested). I'm also planning on writing a Postgres protocol library. It will likely need to support SCRAM-SHA256 authentication, similar to what I've described. This library could be handy for this. - Did you try to use the library? With which compiler(s)? Did you have any problems? I've re-written the password hashing functionality in Boost.MySQL to use the proposed library [2]. Everything has been very smooth. The test suite passes for all the compilers I support [3], which is really good. I'd have liked some utilities on top of HashAlgorithm to make hashing byte sequences safer and easier. These utilities would *not* imply any change in the HashAlgorithm interface: * Adding a contiguous range of bytes to an algorithm currently supports only a pointer + size pair. This is the right choice for HashAlgorithm, but having a helper function on top of it would be great, as proposed by other reviewers. This would make my code go from: // password is a string_view hash2::sha1_160 hasher1; hasher1.update(password.data(), password.size()); auto password_sha1 = hasher1.result(); To: hash2::sha1_160 hasher1; hash2::hash_add_bytes(hasher1, password); auto password_sha1 = hasher1.result(); * Adding a function that computes the hash of an entire byte sequence, as a range, could be useful. OpenSSL has this as SHA1() and SHA256(). This would make my code go from: hash2::sha1_160 hasher1; hasher1.update(password.data(), password.size()); auto password_sha1 = hasher1.result(); To: auto password_sha1 = hash2::compute_hash(hash2::sha1_160(), password); These are just nice to have and trivially implemented in user-land, if required. The code is already good as is today. - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? I have dedicated around 8 hours to study the documentation, build the library and examples, integrate it into Boost.MySQL, update my CIs to run my tests with the library, and write this review. - Are you knowledgeable about the problem domain? I am a mere user of hash algorithms, as I usually write networking code. I don't know about their internals. I haven't authored associative containers, either. - Affiliation disclosure I am currently affiliated with the C++ Alliance. - Final decision My recommendation is to CONDITIONALLY ACCEPT the library into Boost. My only acceptance condition is adding the hash template class developed in the examples to the library. The benefit of having the library in Boost is big and overcomes any concerns I might have. Many thanks to both Peter and Matt. Kind regards, Ruben. [1] https://dev.mysql.com/doc/dev/mysql-server/8.4.3/page_caching_sha2_authenti… [2] https://github.com/boostorg/mysql/pull/389 [3] https://github.com/boostorg/mysql/blob/c438f26731e36c2db6457705ec5dbb9f7657… [4] https://lists.boost.org/Archives/boost/2024/12/258687.php

4 4

Re: [boost] [hash2] My Review
by Vinnie Falco 12 Dec '24

12 Dec '24

On Sat, Dec 7, 2024 at 5:47 AM Matt Borland via Boost <boost(a)lists.boost.org> wrote: > The review of Hash2 by Peter Dimov and Christian Mazakas begins today > Saturday, December 7th through Sunday December 15th, 2024. > > Code: https://github.com/pdimov/hash2 > Docs: https://pdimov.github.io/hash2/ Disclaimer: I am affiliated with The C++ Alliance and I am also a co-author of N3980 (the paper referenced by the library). This is my review of Hash2. Spoiler alert, my suggestion is to: ACCEPT While most of my review is dedicated to discussing some concerns I have about some aspects of the library, it is clear that Boost as a collection is better with Hash2 than without it. Also, Peter is going to do what Peter is going to do so why fight it. The uncontroversial parts are stated first, and after lies my assessment of some questionable design choices. > - What is your evaluation of the implementation? > I looked over some of the implementation to better understand how certain things work. The tests pass on CI and the test code looks comprehensive. Peter is not in the habit of producing anything less than high-quality implementations and this library is no exception. I don't know which parts are from Peter and which are from Christian and the quality appears high throughout. > - What is your evaluation of the documentation? > I think the documentation could be better in places. The named requirements exposition is too informal for my taste and talks about things that are not strictly relevant, such as zero-padding. The library alludes to cryptographic usage yet glosses over some details which surfaced during mailing list discussion (more on that below). It would be nice if there was some exposition up front explaining which groups of users the library is for, and how each group uses the library. > - What is your evaluation of the potential usefulness > of the library? Do you already use it in industry? > Not only is the library useful, but the C++ Standard is poorer for not having a modern hash solution. Competing approaches were developed by Google and N3980, then promptly abandoned. > - Did you try to use the library? With which compiler(s)? Did > you have any problems? > I tried to build a Visual Studio Solution from the CMakeLists.txt after cloning hash2 into my superproject, with this command line: cmake -G "Visual Studio 17 2022" -A x64 -B bin64 -DCMAKE_TOOLCHAIN_FILE="C:/vcpkg/scripts/buildsystems/vcpkg.cmake" -DVCPKG_CHAINLOAD_TOOLCHAIN_FILE="C:/users/vinnie/src/toolchains/msvc.cmake" It started downloading things from the internet (FetchContent I guess) and then failed. I was not able to generate a solution. I asked Peter about this and he said it was not supported. It would be nice if it was. > - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? > I focused primarily on the ways in which the library differs from the original paper N3980. I looked at the relevant documentation, interfaces, and implementation, and engaged the author on the mailing list. - Are you knowledgeable about the problem domain? Fairly knowledgeable. - What is your evaluation of the design? This is where I have concerns. The audience of users for Hash2 can be divided into roughly these groups: 1. Authors of types who just want to make objects of their type hashable without having to learn about hash algorithms cryptography, and users who want higher quality results when working with unordered containers. Hash2 is basically perfect for these two groups of users (which often overlap) although the documentation could be improved to speak more directly to them. 2. Users who wish to calculate a cryptographic digest for objects of Hash2-enabled types, or for untyped binary data. Hash2 is also almost perfect for these use cases, and as before the documentation could be more explicit about these cases. 3. Users who wish to adapt existing code to meet the HashAlgorithm requirements from Hash2. This is where I believe the library has some design problems. An unfortunate consequence of being right almost all the time, is that it becomes more unlikely to recognize when you are wrong. I will assume that the reader is at least somewhat familiar with N3980 and some of the arguments I made about the HashAlgorithm named requirements on the mailing list. Hash2 attempts to improve the quality of life for users by mandating additional requirements for the HashAlgorithm concept which may be difficult or impossible to meet for some existing libraries. For example, it requires that every HashAlgorithm support: * Seeded construction from std::uint64_t * Keyed construction from binary data * Copy construction * Digest extension from repeated calls to result() * Interleaving of calls to update() and result() * ...Future stuff that the author alludes to These issues above are already discussed extensively on the mailing list and I can't be bothered to spend hours putting it all together into a beautiful post the way that some of the other reviewers have done (Andrey Semashev and Samuel Neves come to mind). The burdensome additional named requirements of Hash2's HashAlgorithm ensure that no casual users will be authoring them. Or worse, they will get them wrong and the results will not have the same guarantees as the underlying algorithms. Right now there are approximately 1,649,127 implementations of cryptographic and non-cryptographic hash algorithms. I think it might be more prudent for Hash2 to offer a system of traits for identifying which algorithms are capable of what, such as CopyConstruction, digest extension, and so on, and give the user tools which only work in safe ways given the traits of a hash algorithm. This would make it easier to write HashAlgorithms. And as a consequence we might get many more of them rather than fewer. Realistically I don't expect the library to change, and a proliferation of user-created HashAlgorithms is probably conditional on the Boost library collection being much more popular than it currently is. This is partly why I have decided to just accept the library. And I could be wrong, and Peter's unwavering insistence that users get HashAlgorithms which all offer the same quality of service might turn out to be better. Time will tell. Thanks

2 1

[hash2] Difference from paper: HashAlgorithm interface vs. function object
by Andrey Semashev 12 Dec '24

12 Dec '24

Hi, The HashAlgorithm interface defined in Boost.Hash2 is notably different from the one described in N3980 (https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3980.html) Specifically, the paper defines HashAlgorithm as a function object, whose operator() is equivalent to Boost.Hash2's HashAlgorithm::update method. The function object also provides a conversion operator to result_type, which is equivalent to Boost.Hash2's HashAlgorithm::result method. Is this discrepancy intentional and are there plans (on the paper authors' or the library authors' side) to eliminate it? Personally, I don't think a function object is the right interface for a hash algorithm. Update and finalize are two distinct operations provided by hash algorithms and both should be performed explicitly by the user. I don't think a conversion operator is the right name for finalize. Conversion operators are normally used when one type can meaningfully "impersonate" another, and this is not the case here. The function object is also misusing result_type, as its operator() doesn't return it. The paper discusses that the fact that a hash algorithm is a function object can be used to wrap it in std::function, which can be useful with pimpl idiom and for the purpose of type erasure. I don't think this will actually work, at least not as simple as the paper describes it, because std::function won't allow to extract the computed hash digest (i.e. you won't be able to call the type conversion operator on the wrapped function object). I think, the user will have to write some wrapper classes anyway to retain access to the wrapped hash algorithm. However, this is still an interesting use case. Does Boost.Hash2 intend to provide utilities to address it? For example, Boost.Hash2 could provide a hash-algorithm-agnostic interface for feeding an algorithm with input data, and a wrapper for an external algorithm object that would implement this interface. Something along these lines: class polymorphic_hash_algorithm { public: polymorphic_hash_algorithm( polymorphic_hash_algorithm const&) = delete; polymorphic_hash_algorithm& operator=( polymorphic_hash_algorithm const&) = delete; virtual void update(const void* data, size_t size) = 0; protected: polymorphic_hash_algorithm() = default; ~polymorphic_hash_algorithm() = default; }; template< typename Hash > class polymorphic_hash_algorithm_wrapper : public polymorphic_hash_algorithm { public: using hash_type = Hash; using result_type = typename hash_type::result_type; static constexpr size_t block_size = hash_type::block_size; private: Hash& h; public: explicit polymorphic_hash_algorithm_wrapper(hash_type& h) noexcept : h(h) {} void update(const void* data, size_t size) override { h.update(data, size); } result_type result() { return h.result(); } }; This way, polymorphic_hash_algorithm could be used to abstract away the hash algorithm type while still be compatible with hash_append and friends. As a side note, this would be another use case where the hash algorithm passed to hash_append is non-copyable. And while copyability could be added, most likely it wouldn't be free.

6 11

The Master branch is now open for changes
by Marshall Clow 12 Dec '24

12 Dec '24

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

1 0

[hash2] Question about cryptographic guarantees of hash_append_unordered_range
by Ivan Matek 12 Dec '24

12 Dec '24

Hi everyone, Implementation uses uint64_t in which it sums into hashes of particular elements(each computed with "fresh" hasher so ordering does not matter), then it finally hashes that sum and range size into original passed hasher. I see no problem with logic this since it cleverly exploits the fact that uint64_t overflow is defined and that sum is commutative. But I wonder if this preserves the cryptographic quality of original hash. For example if we use sha2 it seems to me that finding collisions becomes easier since sum is "only" 64 bits, and length is "only" 64 bits(or 32 on some systems), and may be even less if attacker knows unordered range was not super long, e.g. number of items was less than 10000. Does somebody know more about this particular domain and could point me to some resource to learn more? I know it was in the original proposal, but it is possible original proposal was not focusing only on cryptographically secure algorithms. I was unable to google any guarantees, maybe because idk what keywords to use. :)

9 17

[release] Boost 1.87.0
by Marshall Clow 12 Dec '24

12 Dec '24

Release 1.87.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. This release contains two new libraries: * Boost.Parser: A framework for building parsers, from Zach Laine. The release also contains numerous enhancements and bug fixes for existing libraries. For details, including download links, see <http://www.boost.org/users/news/version_1.87.0> You can also download directly from: <https://boostorg.jfrog.io/artifactory/main/release/1.87.0/> 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 Gaztañaga

2 2

[Hash2] Current list of items brought up during review
by Peter Dimov 11 Dec '24

11 Dec '24

This is what I've scribbled so far as a list of to-do items: - add hash_append_range taking a range - add a "provider" argument (providing the hash_append API) to tag_invoke - example of hashing boost::json::value - maybe change argument of tag_invoke to take the value by pointer, rather than by reference - maybe expose has_tag_invoke to users so they can specialize - make byte sequence seed constructor take `void const*` as well - change get_integral_result to take a Hash, instead of h.result(), so that it can invoke result() more than once - a user-accessible way to test whether a hash algorithm conforms to the requirements - add a variadic hash_append overload - hash_append_unordered_range: use more than 64 bits for intermediate hashes (uint64_t[4]); improve somehow https://lists.boost.org/Archives/boost/2024/12/258643.php - acknowledge https://github.com/HowardHinnant/hash_append - in documentation, focus more on the std::hash case, rather than on the md5sum case - in FNV-1a byte seed constructor, include the seed size - change block_size to std::size_t

2 1

Re: [boost] [Hash2] Result extension
by Peter Dimov 11 Dec '24

11 Dec '24

Vinnie Falco wrote: > Sigh.. copy/paste typo. > > /** Return a seeded HashAlgorithm > */ > template< class HashAlgorithm > > HashAlgorithm make_seeded( > unsigned char const* seed, std::size_t n ) > { > if constexpr(std::is_constructible<HashAlgorithm, > unsigned char const*, std::size_t>) > return HashAlgorithm(seed, n); > else > { > HashAlgorithm h; > hash_append(h, seed, n); You can in principle do something like that (except fix it to compile) but (much) better practices would be - hash.update( seed, n ) - encode `n` as 64 bit little endian in 8 bytes - hash.update these bytes - hash.update( "\x80", 1 ) - hash.update( "\x00", 1 ) - hash.update with as many zeroes as needed to reach a multiple of HashAlgorithm::block_size That's, incidentally, exactly what `update(p, n); result();` does. (What an amazing coincidence.) Note that reaching a multiple of block_size is important, because it ensures that the secret key you passed as the seed is not left in the internal buffer of the hash algorithm, visible in memory dumps. The test https://github.com/pdimov/hash2/blob/develop/test/plaintext_leak.cpp tries to catch these mistakes. That's why this line https://github.com/pdimov/hash2/blob/7a25f8518692b657e9272884519519fbaca2ec… is needed, for example. > return h; > } > } > > Thanks >

4 6

Github Actions CI updates - e.g. Node 20
by Alexander Grund 10 Dec '24

10 Dec '24

Dear maintainers, I made a bunch of PRs to fix the Github Actions CI for almost 40 repositories. Opening a PR in GitHub is manual work while I was able to apply similar changes over all those repositories using a script which commits to a single branch (and hence PR) per repo. Hence the PRs contain a few related changes that in combination allow the CI to pass again. To avoid repeating this in each PR I wanted to shortly explain the changes here: 1. macos-12 runners are dropped by github and jobs won't start anymore. at least macos-13 needs to be used 2. Ubuntu 23.* doesn't work anymore as e.g. some APT repositories don't exist anymore. Ubuntu 24.04 can be used instead 3. clang 17 (and partly 16) don't work in C++23/2b mode with the stdlibc++ (12) installed on ubuntu 24.04, clang 18+ and/or the other C++ standards can still be used 4. Support for Node 16 was recently fully dropped by Github Actions so the @v3 actions must be upgraded to @v4, which require Node 20. The workaround using $ACTIONS_ALLOW_USE_UNSECURE_NODE_VERSION has no effect anymore 5. The node 20 version available by default conflicts with the glibc version in the Ubuntu 16/18 container images used for testing older compilers. I addressed all of them with last one being the major one: Installing a compatible version inside a custom image to be used instead doesn't work because GHA mounts the node 20 installation from the host os. The solution I implemented downloads an unofficial node 20 built against the correct/older glibc and creates 2 mount points such that we can put that node onto the host runner and mount that instead of what github gives us using the idea from https://github.com/dixyes/ghactionsplay/blob/bf889ee2fed8dcd72cc8e32bfd4789… To avoid overloading the unofficial-builds.nodejs.org server we use a copy hosted at boost.io Download and extraction requires curl and xz-utils to be installed which I added where required. Additionally I noticed additional failures due to use of C++03 where the dependencies require C++11, or of C++0x using GCC < 4.9 where e.g. C++11 `alignof`, required by the Boost.SmartPtr dependency, is not available. For (only) those I removed the C++03 and/or GCC 4.7/4.8 jobs (which cannot succeed). I think combining those changes into a single PR avoids a lot of additional manual work by me and allows to verify that the changes are sufficient to make CI pass again. Keeping e.g. C++03 builds, that cannot succeed due to dependencies, makes verifying the success of the Node 20 fix harder/less clear If anyone prefers to separate those changes into multiple PRs please mention that in the relevant PR for me to keep track of, or cherry-pick the individual changes. However it might be sufficient to check the status of the CI for the individual commits to compare the state (success/failure) for the jobs fixed or removed by the next commit. I realize maintaining the CI is a PITA and hope this helps. Regards, Alex

6 8

[Release] Boost 1.87.7 Release Candidate 1 is available
by Marshall Clow 09 Dec '24

09 Dec '24

The first release candidates for the 1.87.0 release are now available at: <https://boostorg.jfrog.io/artifactory/main/release/1.87.0/source/> The SHA256 checksums are as follows: f55c340aa49763b1925ccf02b2e83f35fdcf634c9d5164a2acb87540173c741d boost_1_87_0_rc1.tar.gz af57be25cb4c4f4b413ed692fe378affb4352ea50fbe294a11ef548f4d527d89 boost_1_87_0_rc1.tar.bz2 f367a218d27b23b568956bacf56d08d2c1d9647211337136be8cac5cb2ff0828 boost_1_87_0_rc1.zip db6b7d77a2286ebe79d4aa7252c08b051d271fd8b013b6b18bc7a966552c1139 boost_1_87_0_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 11

[Hash2] Result extension
by Peter Dimov 09 Dec '24

09 Dec '24

Vinnie Falco asked me the following on Slack: > I would ask, what is the motivating use-case for calling result > twice? This is not explained in the docs and no examples are > given. In fact, the one example given says "not to do this" Calling result() twice (or more times) provides result extension; the ability to extract variable number of bits from a hash algorithm, instead of a fixed size value (e.g. 64 bit.) This is in fact stated in the docs here https://pdimov.github.io/hash2/doc/html/hash2.html#hashing_bytes_result > Note that result is non-const, because it changes the internal > state. It’s allowed for result to be called more than once; > subsequent calls perform the state finalization again and as a > result produce a pseudorandom sequence of result_type values. > This can be used to effectively extend the output of the hash > function. For example, a 256 bit result can be obtained from a > hash algorithm whose result_type is 64 bit, by calling result four > times. and there is an example of doing that here https://pdimov.github.io/hash2/doc/html/hash2.html#example_result_extension All hash algorithms are required to support result extension, because (in my opinion) this is extremely useful functionality that is easy - even trivial - to provide, but is often withheld either by accident or in some cases, even deliberately. Hash algorithms typically have a "finalization" phase that pads the message, mixes the length, scrambles the internal state in a more thorough manner than in `update`, and then derives a hash value from that state. (The hash value is often shorter than the total amount of state.) If this "finalization" phase is performed more than once, one naturally gets the mandated `result()` behavior. Falco continues: > I pointed out in the post I already made that the quality of > digest from calling result twice is dependent on the hash > algorithm, and there is no way the library can provide > assurances on the quality That's of course correct, but it also applies to the quality of calling `result()` only once; it's naturally dependent on the implementation of the hash algorithm. What's important here is that it's not possible to provide an extended result of better quality from the outside; the hash algorithm is in the best place to provide it because it has access to more bits of internal state than it lets out. This requirement effectively mandates that all _hash algorithms_ be _extendable-output hash functions_: https://en.wikipedia.org/wiki/Extendable-output_function Note that this is not the only innovation that the proposed hash algorithm concept involves. All hash algorithms are required to support seeding from uint64_t and from an arbitrary sequence of bytes, which makes them effectively _keyed hash functions_ (or _message authentication codes_). Also note that the requirement that one can interleave calls to `update` and `result` arbitrarily makes it possible to implement byte sequence seeding (for algorithms that don't already support it) in the following manner: Hash::Hash( unsigned char const* p, size_t n ): Hash() { if( n != 0 ) { update( p, n ); result(); } } Subsequent `update` calls now start from an initial internal state that has incorporated the contents of [p, p+n), and that has been "finalized" (scrambled thoroughly) such that the result is not equivalent to just prepending the seed to the message (as would have happened if the result() call has been omitted.)

4 14

[hash2] Hash Algorithm Requirements versus concepts
by Andrzej Krzemienski 08 Dec '24

08 Dec '24

Hi Everyone, It strikes me that the description of Hash Algorithm Requirements does not use C++ concepts. Even though the library is C++11-compatible, it could use a concept in the documentation. The goal of the concepts was to serve a case like this, so I wonder if this is just an omission from the authors, or if this is an indication that concepts do not deliver their promise. There is the optional `block_size` but this could be modeled by two concepts HashAlgorithm and BlockHashAlgorithm. The type of `block_size` looks like a candidate for another concept HashAlgorithmResult. Regards, &rzej;

1 0

[hash2][review] Early review (due to holidays)
by Claudio DeSouza 07 Dec '24

07 Dec '24

Hello. My review is the summary of a few discussions I've had with Peter and Christian regarding the API design being employed for hash2. I'm aware hash2 is inspired by one of Hinnat's proposals to standardisation that didn't come to fruition. I would like first to commend the authors for their work on this project. Having good libraries for this type of task is important, especially when the big names like OpenSSL provide not-so-great interfaces. Having said that, I have a few thoughts on what this library may be missing. *Spanification* There's a significant change in mood with regards to safe library design taking place in the industry. With clang, we now have -Wunsafe-buffer-usage, and this warning has been continuously improved recently. For reference https://clang.llvm.org/docs/SafeBuffers.html When I was going through this library's code I was left with a frustrating thought that boost should be at the forefront of this type of innovation: safe, and intuitive library design. Each function that takes a pair of void*/size_t should be a span<uint_8>. The model of how to approach these areas is a solved issue at this point. A robust span type with intuitive extensions would have matching constructors for all sorts of contiguous ranges, including native arrays, which would make using this library much simpler. It would also afford the necessary compile-time validations that you get with static extents in a span. At the current state, hash2 relies on a lot of pinky-promise guarantees that we tend to live with in C++, but that in fact can be avoided without much (or any) overhead. *Digest type* Due to limitations to how much of std::array is constexpr in different C++ versions, this library offers its own digest type. However, this just wraps a stack array. I feel that rather than returning a digest that is stack allocated, it would have been better for algorithms to take a fixed size span where the digest can be written to. I say this because in many cases a stack allocated array will be fine. However a mutable fixed span would provide more flexibility about the storage, for instance, a vector. There's also the matter of hardening (https://libcxx.llvm.org/Hardening.html) which one loses by using this particular digest type, rather than storage provided by a standard type. But I would also like to mention that sha3 has a variable digest size, so again, another reason why an out param mutable span would be a more flexible choice on the whole. *Boost Identity* I have been reluctant to write a review because it seems unfair to demand of hash2 to provide robust spanified interfaces, when no other library before was required to do so. However, at the same time, considering that this type of code tends to be used in safety-sensitive contexts, I fear this library may fail to achieve its potential, when a lot of its interfaces are unsafe. if I had to bring this library to any project I'm working on, I would have to wrap it into safe spanified interfaces, to hide away all these pointer/length pairs around, before I could use it in my code. However, I understand that to produce a spanified design, boost would have first to introduce a mature span implementation + extensions that can be leveraged for this type of code design. *Security* I think for things like HMAC, there is a question of allocators that zero-out memory, of secure obfuscated memory content in case of crash dumps, etc, that this library has not been attentive to, so I thought it was worth mentioning. *In conclusion* I'm here to support the authors. I don't feel like voting either accept or reject, because I think Boost as a whole has not provided the mission critical answer to that. I want this library to succeed. I just wish it was a bit more ambitious in its goal on the library-design space. Claudio.

13 107

[hash2] HashAlgorithm's named requirements for result()
by Vinnie Falco 07 Dec '24

07 Dec '24

On Fri, Dec 6, 2024 at 4:24 PM Ivan Matek via Boost <boost(a)lists.boost.org> wrote: > Goal was to "encourage" users in 2 ways to call result() only once. First > way is that move signals that value is "tainted", second is that clang-tidy > can detect double moves sometimes. > I propose to change HashAlgorithm requirements as follows: --- HashAlgorithm result() is renamed to result_type finalize(); The current documentation for finalize [1] is moved elsewhere and replaced with the following text: This function shall return the final hash value of the input message, where the input message is defined by the ordered sequence of bytes provided in all prior calls to update(). The behavior of subsequent calls to finalize() is undefined unless specified by the HashAlgorithm. --- Rationale: The name "finalize" is closer to established practice and is more suggestive of the typical state mutation: https://github.com/openssl/openssl/blob/5fce85ec52a826d53665552b50e67f86c92… The existing Hash2 documentation for result() is too specific and suggests operations which may not be relevant such as for FNV-1a or other byte-oriented algorithms. It would be better to state only the mandatory requirements and leave the rest to the implementation. The existing Hash2 documentation suggests the possibility of calling finalize() twice or more in a row, yet this can only be considered safe, secure, or otherwise generally following best practices on a case by case basis depending on the HashAlgorithm. The HashAlgorithm concept is first and foremost designed for use with the Hash named requirement (std::hash and related). Making calls to a generic finalize() undefined does not hinder this use-case. There has been no research into whether HashAlgorithm should be held up as the concept for how ALL hash algorithms should be modeled. Therefore the named requirements for HashAlgorithm's finalize() function should only go as far as needed to support the Hash use-case, and we should leave the rest of its behavior up to the implementer. In particular I think there is danger here: template< typename HashAlgorithm > auto double_finalize( HashAlgorithm& h ) { h.finalize(); return h.finalize(); } This is dangerous because the usage in generic contexts results in an unpredictable quality of result. We should use the more strict definition I provided above for now, and only in the future loosen the definition if there is evidence that doing so yields a net benefit. It is always easier to go from strict to loose. And going from loose to strict after the fact is difficult and often impossible without breaking things. It is better if double_finalize is undefined. Users who want random numbers or whatever, can do it with a specific implementation of HashAlgorithm which offers additional guarantees for finalize(). [1] https://pdimov.github.io/hash2/doc/html/hash2.html#hashing_bytes_result

2 2

Any interest in a faster "any" type alternative?
by Marcus Tomlinson 06 Dec '24

06 Dec '24

I’m aware that the current implementation of any intentionally avoids copy assignments and uses only copy construction for all value updates. I believe this is due to the fact that copy assignment isn’t always available for all types - understandable. My proposal is what if we had a separate “fast-any” type that does utilise copy assignment when types match. In my own usage of this new type, I’ve found massive (roughly 2x) performance improvement on consecutive assignments of the same type. I’d like to gauge whether there would be any interest in adding such a type to the Boost library. Source code: https://github.com/cross-platform/fast_any Regards, Marcus Tomlinson

2 2

[release] The Master branch is now closed for ALL changes
by Marshall Clow 05 Dec '24

05 Dec '24

Please do not commit to the master branch. — Marshall

1 0

[release] Master branch is now open for bug fixes
by Ion Gaztañaga 04 Dec '24

04 Dec '24

Hi, The master branch is now open for bug fixes, test and documentation changes, but please follow the policy described in: https://github.com/boostorg/wiki/wiki/Releases%3A-Beta-Merge-Policy The next deadline: On December 4th, master closes for all changes. As always, the calendar is at https://www.boost.org/development/ — The release managers

9 22

[release] Reminder: Master Branch closes for all changes TOMORROW December 4th
by Marshall Clow 03 Dec '24

03 Dec '24

For the 1.87.0 release. The calendar is here: https://www.boost.org/development/index.html — Marshall P.S. If you have change notes, don’t forget to add them to the website.

1 0

Boost 1.87-beta1 still has sha1 failure in boost.compute
by Benjamin Redelings 02 Dec '24

02 Dec '24

Hi, It looks like boost 1.87-beta1 still has the compile failures from version 1.86 in boost::compute::detail::sha1. I see that there are patches from Aug 21, 2024 to address this in the `develop` branch of `boost.compute`. Are these likely to make it into boost 1.87? -BenRI

3 3

[release] Boost 1.87.0 beta 1 released
by Marshall Clow 19 Nov '24

19 Nov '24

Boost release 1.86.0 beta 1 is now available at: https://archives.boost.io/beta/1.87.0.beta1/source/ The SHA256 checksums are: 2e7cdf358526e8937b36b93fc96c501b8d6a0c8436e95e65440de31c48ec3086 boost_1_87_0_b1.tar.bz2 98a86940c13509dfd0288a3075280f46a76c9a3faeb8a9bf49ca7f9e6a271995 boost_1_87_0_b1.tar.gz 2ca4c019d0c96fd160dec5292a7a6bfcf7b4e592cd238a2207e17084f8021d08 boost_1_87_0_b1.zip 5ea32facd963dbb79ceb5bda7ef7546017ea5da854158f8933bbad74d6bbe622 boost_1_87_0_b1.7z This is slightly different than the RC3. Someone committed a documentation fix to master after we had started the release process, and rather than re-do the whole thing (and re-tag everything), we decided to go with the release that we prepared. The person who did this has been informed of the problems that he caused, and I don’t think he’ll do it again. Release notes (still need updates): https://www.boost.org/users/history/version_1_87_x.html Please try the beta and report any problems you encounter. Thanks to everyone who contributed to the release. -- Boost Release Team

4 6

Re: [boost] [review] [sqlite]
by Дмитрий Архипов 19 Nov '24

19 Nov '24

пт, 15 нояб. 2024 г. в 15:58, Klemens Morgenstern <klemensdavidmorgenstern(a)gmail.com>: > Would you also suggest automatic conversions or just stick to sqlite::value ? To be honest, I'm not sure. Automatic conversions would also have to rely on deduction, which would again inhibit the use of templates and overloaded functions. > I think you're right. I didn't really like the context idea in your > previous code example, but I think this can be rectified: instead of a > context object, you can pass in a tuple that gets forwarded to the > constructor of the function. > ... > create_aggregate_function<collect_libs, 1>("my-prefix", 42); First, I realised that there's no need to put any additional shared data into SQLite-managed memory, as you can always just add a reference member to the callable and store that shared data on your side. Second, I assume the point of this approach is to avoid copying the callable object, and also support non-default constructible callables. My approach uses the original callable as a kind of prototype, from which it copies new objects for every operation. To be honest, I don't think there should be any difference in performance between my approach with copying and yours with constructing. Ergonomically, I think mine is better. Yours may be looking more straightforward to users. One idea came to my mind. It's sometimes hard to determine which parts of the SQLite C API are supported by your library, and what specific components do it. So, I think you need a dedicated list of all SQLite C functions with comments like "supported via sqlite::backup", "supported via sqlite::mutex", "not supported because an analogous function X is supported ", "not supported because deprecated by SQLite", etc.

2 1

[graph] Temporary maintenance delays until the new year
by Jeremy Murphy 18 Nov '24

18 Nov '24

Dear Boost.Graph users, I'm in the process of moving to another country and changing jobs at the moment, so apologies that there has been and will continue to be a period of slow responses to (some) pull requests, etc until I get settled into a new routine. Regards, Jeremy

1 0

Re: [boost] [review] [sqlite]
by Ruben Perez 16 Nov '24

16 Nov '24

(CC-ing the list) On Sat, 16 Nov 2024 at 12:11, Klemens Morgenstern <klemensdavidmorgenstern(a)gmail.com> wrote: > > On Sat, Nov 16, 2024 at 7:07 PM Ruben Perez <rubenperez038(a)gmail.com> wrote: > > > > > > 3. What's the rationale behind BOOST_SQLITE_NO_VIRTUAL? Wouldn't > > > > setting it cause trouble, being a compiled library? > > > > > > It would. The idea is that you can use that for constrained (i.e. > > > embedded environments) to avoid the unnecessary vtable and to enforce > > > devirtualization if your compiler misses this. > > > > If I have read the code correctly, these functions seem to only be > > used in headers. Why do they need to be virtual? It looks like it > > could have been made a compile-time interface (i.e. a concept), > > completely avoiding the need for the macro. What's the rationale > > behind this? > > That's correct, that's also what it was originally. But the error > messages were horrendous. > By creating a base class you get good error messages (purely virtual > because method X is missing) and the compiler is still compelled to > devirtualize by the way it's used. > And because it's effectively unused, you can disable it. Couldn't you achieve a similar effect (scoped to C++20 and later) by conditionally using concepts? In a way similar to what Asio does to diagnose completion tokens (i.e. BOOST_ASIO_COMPLETION_TOKEN_FOR).

2 1

Re: [boost] [review] [sqlite]
by Ruben Perez 16 Nov '24

16 Nov '24

(CC-ing the list) On Sat, 16 Nov 2024 at 11:55, Klemens Morgenstern <klemensdavidmorgenstern(a)gmail.com> wrote: > > On Sat, Nov 16, 2024 at 6:47 PM Ruben Perez <rubenperez038(a)gmail.com> wrote: > > > > What's the current recommended way to consume the library? Installing > > it with CMake seems to only install the binaries (and not the > > headers/cmake find_package scripts), and I haven't found a Jamfile to > > build the library as part of the Boost superproject. > > FetchContent + add_subdirectory is what I do. > > There also is a Jamfile in /build, but it's going to just to sqlite3, > because there's no `using sqlite ;` available at the moment. That's > probably only going to work on linux as of now. > Thanks, I completely missed out the Jamfile because of an unfortunate IDE setting.

1 0

[release] Boost 1.87.0 Release Candidate 3 is available
by Marshall Clow 15 Nov '24

15 Nov '24

The third release candidates for the 1.87.0 release are now available at: <https://boostorg.jfrog.io/artifactory/main/release/1.87.0/source/> The SHA256 checksums are as follows: 10ea784394be84794ed8981643ea0f05fae38de6aa595353115f85c79e4c1cd7 boost_1_87_0_b1_rc3.tar.gz 56db0fc204e6e0e40e1764800ef82475c96916e86112bc9627d1b94102cb786a boost_1_87_0_b1_rc3.7z 45fcc8f7f63e023cdafc1d88b3b915f3feac6bc7aab52a91d5766b5a2248af6d boost_1_87_0_b1_rc3.zip e0c971e3b92aa8ab781fe8239e050078600a446bd26c4509001037872974c4c2 boost_1_87_0_b1_rc3.tar.bz2 Changes since RC2: * The Boost.Parser library is included * A bug that caused compile failures in stl_interfaces with recent versions of clang has been fixed. * A bug that caused compile failures on Boost.Proces with gcc has been fixed. 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

5 11

Status of the 1.87.0 Beta Release
by Marshall Clow 12 Nov '24

12 Nov '24

There have been a couple of minor problems reported against RC2. However, yesterday we noticed that Boost.Parser was not part of the RC. We will be issuing an RC3 later today to rectify this. Unfortunately, this means that the beta release will be delayed by a couple of days — The Release Managers

1 0

[fsa] Current status of Fiscal Sponsor Agreement (repost)
by Joaquin M López Muñoz 12 Nov '24

12 Nov '24

(Reposting as PDF) Hi everyone, From the Fiscal Sponsorship Committee, we'd like to share with you the current status of the creation of the new Fiscal Sponsor Agreement for Boost: https://drive.google.com/file/d/1jVggIrQsl4FPrh3H3n-qmy60BclXSILS/view?usp=… We'll be sending periodic updates on this issue. Don't hesitate to ask about any doubt you may have. Best, Joaquin M Lopez Munoz The Fiscal Sponsorship Committee

2 1

[release] Boost 1.87.0 Beta 2 Release Candidate is available
by Marshall Clow 11 Nov '24

11 Nov '24

RC1 had some build issues which have been corrected. Available at: https://archives.boost.io/beta/1.87.0.beta1/source/ The SHA256 checksums are as follows: d24c351fdeaeefa4f25ce5e9365e9d69b86d342570eaac649e3b12f244a6eef7 boost_1_87_0_b1_rc2.7z 98090d258e1d50db30b549072a5db04210350fa7a5ede47d2c71a78af6724e55 boost_1_87_0_b1_rc2.zip 85075e27e6f866cbe3a00f1d5a57e801ce313119dcfd8327babf554c84af9ec3 boost_1_87_0_b1_rc2.tar.bz2 48e51ddfb67eace9181be87f2f25a06dace5e0eb4a84ab803ebfcd8d98e4aab1 boost_1_87_0_b1_rc2.tar.gz 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

7 7

Formal Review Retrospective
by Vinnie Falco 11 Nov '24

11 Nov '24

Ironically, a robust discussion regarding the review process and the usage of Slack is now taking place... on Slack. Arnaud made this suggestion which I am reposting here: "... formalizing a "Retrospective" phase as an actual part of the Formal Review could be key in avoiding criticism against the process to leak into criticism against the proposed library." I think this is a great idea. After each formal review result is announced, there is a new "retrospective" thread started which allows the community to reply and weigh in on how they thought the review was conducted. This actually happened organically in the last review of async-mqtt5 and I think it could be enhanced if the review wizard or review manager had pre-emptively started a retrospective thread where the replies could be accumulated. The subject line could for example be "[async-mqtt5] Review Retrospective" What do you think? Thanks

8 22

[fsa] Current status of Fiscal Sponsor Agreement
by Joaquin M López Muñoz 11 Nov '24

11 Nov '24

Hi everyone, From the Fiscal Sponsorship Committee, we'd like to share with you the current status of the creation of the new Fiscal Sponsor Agreement for Boost: https://docs.google.com/document/d/1fMvWJi0guPCVI_YSD86FTgTMpf69lGiwRs0lgAa… We'll be sending periodic updates on this issue. Don't hesitate to ask about any doubt you may have. Best, Joaquin M Lopez Munoz The Fiscal Sponsorship Committee

1 0

async-mqtt5 is CONDITIONALLY ACCEPTED
by Klemens Morgenstern 09 Nov '24

09 Nov '24

Hi all, thanks to everyone participating in the review! I really want to express my appreciation to the reviewers, especially those who invested multiple hours if not days to review this library: thank you Vinnie, Ruben, Mohammad and Marcelo. I interpreted Darylls review as a "weak rejection", but since that doesn't exist in the formal review process I'll count it as a rejection. Leaving the recommendations at 1 ACCEPT 3 CONDITIONAL ACCEPT 2 REJECT The actual conditions for acceptance are: 1. Correct usage of the executor. It is an asio contract that the async operation always completes on the associated executor and mqtt5 should follow this. 2. Add logging/reporting facilities. A user should be able to follow what is happening internally and ideally react to it, especially concerning reconnects. I also recommend the authors to review all the comments, including the rejections (Daryll's review had interesting details) and non-review comments such as from Peter Turcan. I would also advise that inclusion in boost is usually a time to change the name, because the library now gains the boost. prefix. I.e. boost.async-mqtt5 might be a bit cumbersome. Also note that there is no time requirement to include this library in boost in the next release. Thanks again to everyone participating in the review and to Ivica & Mireo for their submission.

15 47

Slack and Formal Reviews
by Vinnie Falco 09 Nov '24

09 Nov '24

We need to solve the problem of review conversations taking place on Slack instead of the list. I would ultimately love a technical solution that allows discussions to also happen on Slack in a way that preserves the integrity of the review, and that might not be practical right this second. Therefore, I propose the following: 1. Formal review announcement will remind participants that conversations should happen on the list (and specifically mention that Slack should not be used) 2. If a Slack conversation is initiated during the review period, the review manager and library submitter will politely remind folks to move the discussion to the list. Perhaps some copy and pasting will be needed. 3. Periodic reminder from the review manager during the review process, if things get out of hand. 4. We explore ideas for how to incorporate other platforms into the review process. Mailing list participation is down, yet Slack participation is up. Ideally we figure out how to harness change instead of taking on losing battles. -- Regards, Vinnie Follow me on GitHub: https://github.com/vinniefalco

1 0

Shared memory path to custom path
by Murali Kishore 08 Nov '24

08 Nov '24

Hi all, Is it possible to change the shared memory segment path from /dev/shm to other directory ex. /tmp/shm_file instead of /dev/shm/shm_file. Regards, Murali Kishore

3 4

[release] Boost 1.87.0 Beta 1 Release Candidate is available
by Marshall Clow 08 Nov '24

08 Nov '24

Available at: https://archives.boost.io/beta/1.87.0.beta1/source/ The SHA256 checksums are as follows: 26f987635320854a141a8c9c3750eb6f01edb6eb75df9454726c4a03724b2472 boost_1_87_0_b1_rc1.tar.gz 3712ead87a26ae5b8ee7dcf0c180e4c27f58e50bd32f14d77e8e04bf6a13ae51 boost_1_87_0_b1_rc1.zip e6b047e06369392241f8574a5cc1b6aa493819aa498276654477e3a08bc94167 boost_1_87_0_b1_rc1.7z deff255d96e11760f728f5f90785b138fff93f6c9a3ab24664710211a41614ad boost_1_87_0_b1_rc1.tar.bz2 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

4 6

[Release] Master branch is now closed for the beta release
by Marshall Clow 07 Nov '24

07 Nov '24

Master is closed for all changes. See the release schedule at: https://www.boost.org/development/index.html -- Release managers

1 0

[release] Master branch closes for the 1.87.0 beta release on WEDNESDAY
by Ion Gaztañaga 05 Nov '24

05 Nov '24

Calendar is here: https://www.boost.org/development/ — The Release Managers

1 0

Bringing Boost.Array up to date?
by Peter Dimov 05 Nov '24

05 Nov '24

I recently needed to make use of std::array in a constexpr context, and was rudely informed by the compilers that a lot of its features are only constexpr in C++17 (non-const access) or even C++20 (operator==). This makes the standard std::array not very useful in C++14 constexpr code. Ordinarily, the way we deal with such problems is to shadow the standard component in Boost.Compat and backport all features introduced in later standards. But in this specific case, we already have boost::array, and it makes no sense to introduce another one. boost::array, however, looks mostly abandoned. The thinking there was probably that it's rendered entirely obsolete by std::array, and that no further development is warranted or required. But as outlined above, this is not the case; there's still value in maintaining boost::array and keeping it up to date. I'd like to do something about that. If Array's current maintainer, Marshall, agrees, I'd like to take over the maintenance of Boost.Array and do the usual thing - port the documentation to AsciiDoc, expand the test suite, add the necessary BOOST_CONSTEXPR/BOOST_CXX14_CONSTEXPR annotations, add the features introduced by later standards such as deduction guides and to_array, deprecate/remove the nonstandard parts of boost::array that are no longer relevant in 2024, and so on. Comments?

2 1

[release] The 1.87.0 release will close for major changes WEDNESDAY
by Ion Gaztañaga 05 Nov '24

05 Nov '24

Calendar here: https://www.boost.org/development/ Next deadline: The master branch will close for the beta next Wednesday. — The release managers

4 4

[async-mqtt5] Formal review starts today
by Klemens Morgenstern 28 Oct '24

28 Oct '24

Hi all, the formal boost review of the async-mqtt5 library strats today, the 16th of October and will last until and including the 25th of this month. Async.MQTT5 is a professional, industrial-grade C++17 client built on Boost.Asio. This Client is designed for publishing or receiving messages from an MQTT 5.0 compatible Broker. Async.MQTT5 represents a comprehensive implementation of the MQTT 5.0 protocol standard, offering full support for publishing or receiving messages with QoS 0, 1, and 2. The library has been developed by mireo, a GPS/GIS software development company, and their CTO Ivica Siladić submitted it. The code under review is the current master, which is tagged as v1.0.2: https://github.com/mireo/async-mqtt5/releases/tag/v1.0.2 The documentation can be found here: https://spacetime.mireo.com/async-mqtt5/ Please explicitly state that you either *accept* or *reject* the inclusion of this library into boost. Also please indicate the time & effort spent on the evaluation and give the reasons for your decision. - Does this library bring real benefit to C++ developers for real world use-case? - Do you have an application for this library? - Does the API match with current best practices? - Is the documentation helpful and clear? - Did you try to use it? What problems or surprises did you encounter? - What is your evaluation of the implementation? - Do you have experience with asio? - Did you work with MQTT in the past? 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. Reviews can also be submitted privately to me, and I will not disclose who sent them. I might however cite passages from those reviews in my conclusion. I think I should mention that there's another mqtt library that has been proposed for boost, but has yet to find a review manager: https://github.com/redboltz/async_mqtt Some ideas of how we could review them together have been discussed on the mailing list, but this is an independent review of mireo's async-mqtt5. You don't have to consider redboltz/async_mqtt when writing your review. Thanks to Mireo & Ivica for submitting this library.

8 17

[async-mqtt5] Review ends tomorrow
by Klemens Morgenstern 27 Oct '24

27 Oct '24

Reminder: the review period for async-mqtt5 will end tomorrow on Monday the 28th. Thanks for all the great reviews received so far!

1 0

async-mqtt5 review
by Christian Mazakas 25 Oct '24

25 Oct '24

I'm going to vote that we REJECT async-mqtt5 from Boost. My primary reasoning is that so far almost all the review discussion I've seen is focusing solely on the Asio aspect which makes this a miss. I like Asio, and I've used it to deliver products as well. But I don't think this is the MQTT library for Boost. I think libraries like these are a mistake because they're so heavily focused on the ceremony of Asio that the actual meat and potatoes of the library is lost, which in this case is supposed to be MQTT parsing and serialization and broker management. I think there's a lot of utility in MQTT, but what I'd like to see in the future for libraries like these is a first-class interface _without_ I/O. For example, I'm not sure I saw any fuzzing of the underlying parsing code. A non-I/O based interface makes this trivial. I also have a lot of concerns here because the library uses Asio in its interfaces and it also internally uses Spirit. I haven't tried to compile anything but I can only imagine the binary size and the compilation times for a realistic project using this code. I don't have a lot of experience with MQTT as a protocol but my operating assumption is that if TLS/SSL can be made without I/O, so can anything else. I think exploring this design space will lead to a much better outcome for a library going into Boost. You can see prior art here via rustls, OpenSSL's BIO pairs, and Botan which uses a synchronous callback-based interface for handling things. By focusing on creating a pure protocol library, you give users the ability to add MQTT to their own I/O layers which has the extensibility and genericity I'd expect from a Boost library. It will also likely enable the library to be compiled which in this case would be a huge boon. For example, I have an asynchronous runtime which is dramatically faster than Asio and I'm capable of handling low-level networking coding but I can't use this library with my own. Instead, I'd have to roll my own MQTT support. In the ideal case, I'd be able to treat this library like I would Botan and I'd add MQTT support non-intrusively. All this being said, a protocol library that comes with an Asio-based impl is perfectly fine. My only qualm is when the library _only_ supports Asio as seems to be the case here. - Christian

8 14

[async-mqtt5] Review questions
by Ruben Perez 25 Oct '24

25 Oct '24

Hi Ivica, First of all, thanks for submitting your library to Boost. I've been reading the discussion and reference and have some questions for you: 1. The limitation listed on https://spacetime.mireo.com/async-mqtt5/async_mqtt5/auto_reconnect.html about concealing configuration issues looks concerning, as it can be very frustrating for the user. As far as I know, Boost.Redis solved it by including logging as part of its API, and Boost.MySQL did it by providing an extra diagnostics output argument, populated on operation cancellation, that informs the user of potential causes to the problem. Neither of us are very happy with our solution, to be frank. But I think it's a point that might be worth solving before going into Boost. As an option, I have been looking into abusing Asio handler tracking (https://live.boost.org/doc/libs/1_86_0/doc/html/boost_asio/overview/core/ha…) to log custom events. BOOST_ASIO_HANDLER_OPERATION might be a possibility. What are your thoughts regarding this? 2. Quoting the allocators section (https://spacetime.mireo.com/async-mqtt5/async_mqtt5/asio_compliance/allocat…) "[...] associates the allocator of the first packet in the queue to the low-level Boost.Asio function async_write on the transport layer". Does this mean that the queue might use the allocator bound to the first async_publish operation that is issued? If this is the case, wouldn't it be violating the requirement that all memory allocated by an associated allocator is deallocated before the async operation completes? 3. Quoting the executors section (https://spacetime.mireo.com/async-mqtt5/async_mqtt5/asio_compliance/executo…) "The same executor must execute mqtt_client::async_run and all the subsequent async_xxx operations". This sounds like an unusual restriction. What happens if it is violated? Wouldn't it make more sense to use the executor associated with async_run for intermediate handlers, and then the async_xxx associated executor for the final one? 4. I noticed that async_mqtt5 does not implement persistent and clean sessions. I'm no MQTT expert, so I can't evaluate whether these features are relevant or not - I just know that they exist. Is there a reason why you chose to not implement them? If so, I'd suggest adding these reasons somewhere in the docs. 5. According to what I read in the docs, message payloads might contain UTF-8 encoded text or just data blobs, depending on the payload_format_indicator property passed to publish. However, std::string is always used for payloads. As I understand it, if I want to send a binary blob, I need to copy my blob to a string (probably with a reinterpret_cast in the way), and then setting payload_format_indicator. Would it make sense to expose a simpler API taking a blob (e.g. a std::vector<unsigned char>) to make this use case safer? 6. I can't find any docs (other than the examples) on how to use TLS. >From the simplest example (https://spacetime.mireo.com/async-mqtt5/async_mqtt5/hello_world_over_tls.ht…) it looks like setting up TLS requires defining some non-trivial template specializations. I'd like these to be documented. On the other hand, the specializations seem to be using only Boost.Asio types, rather than user-defined types. What would happen if two libraries separately define these hooks because they need MQTT over TLS? Wouldn't it make more sense to provide an optional header providing these functions? 7. What's the use of the TlsContext type in mqtt_client? It looks very coupled to asio::ssl::stream. 8. I've noticed that async_receive returns with an error code whenever a reconnection occurs, which forces the user to re-subscribe to topics. This contrasts with how async_publish works, where reconnection is transparent to the user. Is there a reason for this difference? Would it make sense to implement automatic resubscription on reconnection? Regards, Ruben.

6 12

Summer Mentorship / Volunteering
by Vinnie Falco 24 Oct '24

24 Oct '24

Do any library authors or maintainers: * Desire to mentor a student, and * have the skill to mentor a student, and * have appropriate student work in one of their libraries? If yes please reply with the library and the nature of the work :) Thanks

2 1

[async-mqtt5] Mohammad's review
by Mohammad Nejati [ashtum] 23 Oct '24

23 Oct '24

Hi everyone, This is my review of the proposed async_mqtt5 library. First, I want to thank the Mireo team for submitting this library and Klemens for managing the review process. > Does this library bring real benefit to C++ developers for real world use-case? Developing a high-quality MQTT client library is no small task, and it is not something everyone wants to take on alongside their main project. Having a well-implemented and tested library would be highly valuable for C++ developers. > Do you have an application for this library? > Did you work with MQTT in the past? I have limited experience with MQTT from a previous job where I used the mqtt_cpp library to transmit and receive telemetry data in the telecommunications industry. > Does the API match with current best practices? The API simplifies library usage by providing high-level features, such as automatic reconnection, which is often essential in platforms where MQTT is used. The initiator functions adhere to Asio best practices, allowing users to provide their own executor and allocator, and include proper cancellation support. I believe there’s room to add interfaces for bulk receive and publish operations, which could enhance performance by minimizing rescheduling. This could be considered in the future based on user demand. `mqtt_client` is templated on the stream type and TLS context, which isn't inherently a problem, but it has made Boost.Beast a required dependency, which feels like a design flaw. I suggest abstracting the stream type and its required functionalities into a separate type, allowing users to just include the required implementations of it. I believe `mqtt_client` can type-erase the stream type without any measurable performance impact. All operations on the stream occur at a low frequency, so one level of indirection shouldn't matter. The only higher-frequency operations are `async_write` and `async_read_some`, but since `async_write` uses scatter/gather pattern and passes all buffers in a single call, and `async_read_some` reads into a large buffer, the number of calls to these functions will still be low. I didn’t find the `mqtt_client::brokers` interface very elegant; it could accept a range of hosts and ports and delegate the parsing of a comma-separated list to the users. > Is the documentation helpful and clear? While the documentation does a great job explaining design decisions and corner cases, I'd love to see a beginner-friendly section (like the example in the introduction) that walks through a few examples step by step. This is likely the most-read part of any library documentation and deserves more attention. > Did you try to use it? What problems or surprises did you encounter? I've tried experimenting with the provided examples on a locally run mqtt broker. The obvious problem was that there is no error reporting when things go wrong. This is a side effect of having infinite internal reconnections and no mechanism for reporting them. A logging solution or callbacks for reporting problems would be necessary. > What is your evaluation of the implementation? The implementation has a high quality and shows the authors have a very good understanding of Asio and asynchronous programing. Other than the mentioned issue with stream type, I couldn't find any significant problem during the review. I suggest specializing asio::associator instead implementation associator functions one by one: https://www.boost.org/doc/libs/develop/doc/html/boost_asio/reference/associ… Instead of using the associated allocator of the completion handler to allocate the internal queue, it might be possible to use a form of circular buffer to eliminate the need for frequent memory allocation (this might also fix the total cancellation problem in async_publish). > Do you have experience with asio? Yes, I've been a user of Asio and currently maintain Boost.Beast. > How much time did you spend on this review? I spent about 18 hours reading the documentation, reviewing some parts of the implementation, and experimenting with the interface. > Final decision and comments I vote that we conditionally accept `async_mqtt5` into Boost with the following criteria: - Break the hard dependency on Beast and TLS stream by either abstracting the stream type and placing different implementations in separate headers, or by type-erasing the stream type and constructing the connection through a factory. The type-erasure method is preferred, as it can reduce compile times and simplify usage. - Provide a mechanism for reporting connection errors and reconnection attempts to the user. - Set limits on all internal queues and allow TCP's back-pressure to regulate the speed of the producer and consumer sides. - Introduce address, UB and memory sanitizer to CI builds. Thanks, Mohammad.

3 4

[async-mqtt5] Ruben's review
by Ruben Perez 23 Oct '24

23 Oct '24

Hi all, This is my review of async_mqtt5. First of all, thanks Ivica and the Mireo team for submitting this library for Boost review, and Klemens for managing the review. - Does this library bring real benefit to C++ developers for real world use-case? Yes. MQTT clients are widely used in the IoT world. Boost.Asio is one of the strongest networking libraries in C++. Bringing these together in a high-quality library is valuable. The library already has already more than 140 stars on GitHub, which is a good sign. - Do you have an application for this library? Not right now. But I used to work in the IoT world, and I would have used it if I would have had it available back then. - Does the API match with current best practices? It does almost everywhere. Analysis follows. 1. It's only a high-level API, akin to Boost.Redis. This may not cover some very specialized use cases, but makes it much easier handling common tasks robustly. I don't think this is concerning, since the API is flexible enough. Moreover, the Mireo team has more field experience regarding the protocol than I do. A lower level client can be added in the future without breaking compatibility, if requested by users. 2. It correctly follows Boost.Asio universal async model (except for a gotcha with executors, see my next point), accounting for allocator customization, custom completion tokens, and per-operation cancellation. Looking at the code, it's clear that the developers bear a deep understanding of Asio, which is very valuable. 3. At the moment, the client requires the following: "The same executor must execute mqtt_client::async_run and all the subsequent async_xxx operations." (quoting https://spacetime.mireo.com/async-mqtt5/async_mqtt5/asio_compliance/executo…) This is a deviation from the standard Asio model, not present in any of the libraries currently in Boost. The former statement makes the following malformed, without any diagnostic being emitted: cli.async_run(asio::bind_executor(ex1, ...)); // 1 cli.async_publish(asio::bind_executor(ex2, ...)); // 2 cli.async_publish(asio::bind_executor(ex3, ...)); // 3 Where operations 2 and 3 may complete on any of ex1, ex2 or ex3. I think this limitation should be lifted, and that the above code should be legal. I'd suggest making stream writes child agents of async_run, instead of async_publish and similar functions (see https://lists.boost.org/Archives/boost/2024/10/258132.php for the discussion regarding this issue). 4. The client is templated on the stream type. This is a well-tested design pattern, but can lead to higher compile times. Writing dynamic clients (where the transport type or TLS usage is determined by a runtime variable) is also more involved. I think the current architecture is acceptable, but I'd consider adding a type-erased client in the future. While this shouldn't be too much effort for well-versed Asio developers, regular users may find it unsurmountable. Alternatively, I'd also be good with completely replacing the templated client with a type-erased one (up to the authors). 5. The library internally buffers outgoing and ingoing messages automatically, which is great because it's easier to maintain resilience. However, the only limit on the publishing side are the limited 2^16 packet IDs (restricted by the protocol), with no limit on the reading side. I'm slightly concerned about applications buffering too much on either side. I don't know if this is a real concern or just produced by my lack of MQTT field experience. Would it make sense to somehow introduce a per-topic limit on the number of unacknowledged messages on both the subscribing side (possibly specified when the client subscribes) and on the publishing side? If that's not possible, I'd like to see an example on how to implement this flow control limit on the publishing side, at least. 6. Some APIs use owning types (std::vector and std::string) where non-owning types (boost::core::span and std::string_view) could suffice. I'd suggest reviewing these. 7. TLS streams require a number of template specializations to set up. At the moment, this must be done by the user even for the usual asio::ssl::stream. This risks ODR violations if two libraries end up defining such specializations independently. I'd advise placing the required boilerplate code, together with helper typedefs, in an optional, separate header. 8. The API is really small, and I think that's great. - Is the documentation helpful and clear? It is in general well written and clear. It is however geared towards a user that knows Asio and MQTT pretty well. I'd suggest a couple of changes: 1. There are a lot of pages justifying design decisions made by the library. This has been very useful to me, but is geared towards advanced users. I'd attempt to gather all pages explaining how to use the library in the first section, and move pages with design rationales to a second section. 2. There is no page in the discussion addressing how to use async_publish and async_receive (only an example). This new page should likely go into the first section. 3. There is no page in the discussion addressing TLS. 4. I miss an example about custom authentication. 5. I don't think the multi-threaded example captures the problems that a multi-threaded program integrating the library may face. Running everything under a single strand negates the benefit of multi-threading. I'd target the publisher example, instead. It's important that you ensure that reading the sensor happens outside the strand. I have more minor comments, included at the bottom of this email. - Did you try to use it? What problems or surprises did you encounter? I built a sample publisher and subscriber, based on the examples. They're available here: https://github.com/anarthal/async-mqtt5-test The publisher reads two sensors at different frequencies, which is something that scales poorly when using threads. The async architecture makes this task trivial, which is great. Note that the publisher doesn't co_await async_publish, because that'd prevent further sensor reads, reducing the benefits of resilience. The publisher example in the docs may consider mentioning this. Debugging config issues is extremely difficult (see https://spacetime.mireo.com/async-mqtt5/async_mqtt5/auto_reconnect.html for a rationale). I initially tried to use a public test broker that rejected my connection because of high utilization. It took me a decent amount of time to figure it out - I tried debugging, enabling Asio handler tracking, until I finally launched Wireshark and figured it out. This is a problem during development but also in production, as logging when things go wrong is a usual practice. I think this should be somehow addressed, at the very least by suggesting to use Wireshark/tshark (or other tools that may be practical) in the docs. When using TLS, using SSL_CTX_set_keylog_callback (https://docs.openssl.org/1.1.1/man3/SSL_CTX_set_keylog_callback/#synopsis) to create a keylog file for Wireshark may also be useful, and mentioning how to do it may be useful. I'd at least consider the possibility of including some sort of logging or diagnostics generation, either by using a custom macro or abusing Asio handler tracking. I found that the implementation does not correctly shutdown TLS and websockets (no calls to asio::ssl::stream::async_shutdown and beast::websocket::stream::async_close). These should be added (https://github.com/mireo/async-mqtt5/issues/18) - What is your evaluation of the implementation? The implementation is well written and very easy to follow, which is great. Build times are pretty high, which is not great. The sample publisher takes 22s to build under clang-18, Linux, Debug, C++23 on my machine (30s in Release mode). Building with -ftime-trace, two points show up in the flame graph: 1. The client header includes boost/beast/websocket/stream.hpp, even when not using websockets. The header is very heavyweight and slows down compilation. I think the class can be forward declared if the definition of rebind_executor for websocket streams is changed to the following: template <typename Stream, bool deflate_supported, typename Executor> struct rebind_executor<boost::beast::websocket::stream<asio::ssl::stream<Stream>, deflate_supported>, Executor> { using other = typename boost::beast::websocket::stream< asio::ssl::stream<typename rebind_executor<Stream, Executor>::other>, deflate_supported >; }; Some other Beast headers are included in detail/connect_op.hpp. Connection attempts to distinguish whether the stream is a websocket using metaprogramming, and then runs Beast-specific code when a websocket is detected. I think this creates too much coupling between the libraries. My suggestion is to re-architect this a bit. I'd rewrite websocket detection as a separate trait, and then provide a definition for it in a separate header, thus making Beast a peer dependency. Beast is also use for get_lowest_layer. I don't know if this is strictly required, since asio::ip::tcp::socket does implement the layered protocol (it defines a lowest_layer_type and a get_lowest_layer function, see asio::basic_socket). 2. asio::append and asio::prepend are heavily used, which are heavy to instantiate. I'd suggest experimenting with replacing these by a custom handler class that specializes asio::associator to propagate associated characteristics, as suggested in this ML post: https://lists.boost.org/Archives/boost/2024/10/258132.php. This may or may not reduce compile times, but it's worth a try. The library has many Boost dependencies. While this might not itself impact compile times, it affects package managers. Using Boostdep, the dependency with most transitive dependencies (by far) is Spirit, pulling in variant, thread, preprocessor, phoenix, and a number of other libs. The obvious solution would be encouraging the author to remove the dependency. But I think we have something off in how we manage dependencies in Boost, since the parts of Spirit they're pulling don't require most of these libraries. Regarding testing, I like seeing both unit and integration tests. Code coverage is great. I haven't looked into them in great detail, but from some snippets I saw and Ivica's comments, they seem correctly architectured. I miss sanitizers, fuzz testing and some compilers. See my comments below. - Do you have experience with asio? Yes. I developed and maintain Boost.MySQL. - Did you work with MQTT in the past? I know the basic concepts and have read part of the spec for this review. I haven't used MQTT in production. I have worked in embedded systems before, though. - How much time did you spend on this review? I spent around 25h reading the documentation, reference, researching MQTT, building code snippets and discussing design decisions on the mailing list. - Final decision and comments My recommendation is to CONDITIONALLY ACCEPT async_mqtt5 into Boost. It's a great library and I'd love to see it in Boost. Here are a lot of feedback points, in decreasing order of importance. 1. Acceptance conditions: I think these should be addressed before Boost integration. - Executor correctness. The restriction of forbidding different executors for different operations should be lifted. - Making debugging configuration easier. This can have the form of a documentation page explaining the available tools and how to use them, or by enhancing the current API with logging facilities. - TLS/websocket shutdown code should be added, as per https://github.com/mireo/async-mqtt5/issues/18. 2. Recommendations. These are not acceptance criteria, but I strongly recommend considering them, at least: - Remove the hard dependency on Boost.Beast websocket in detail/rebind_executor.hpp by forward-declaring websocket::stream. - Change the websocket connect handling from if constexpr to traits, to remove the Beast hard dependency. - Consider creating an optional header containing the required boilerplate to use TLS-based connections without the need of template specializations. Helper typedefs could be beneficial. - Experiment with build times and -ftime-trace by reducing the usage of asio::prepend and Boost.Spirit in the implementation. If this happens to improve build times, consider applying the relevant changes. - Introduce fuzz testing for the encoders and decoders (I can aid with this if required). - Introduce address and undefined sanitizer builds (I can also aid with this). - Consider supporting total cancellation in async_publish and other functions. Probably requires fixing the executor issue. - Consider introducing a type-erased client that does not depend on the stream type. I'd consider acceptable entirely removing the templated one in favor of the type-erased one, if the authors feel comfortable with that. - Consider changing the mqtt_client::brokers signature to take a span<host_and_port>, where host_and_port contains a string and a port number. I think this better represents what the function does. - Consider changing usages of std::vector and std::string in public APIs to boost::core::span and std::string_view where it makes sense. - Consider introducing APIs to limit the message production/consumption rates per topic. If not feasible, introduce an example on how to rate-limit a publisher user-side. - Consider trimming some Boost dependencies to make the library lighter for package managers. 3. Minor comments. These are not acceptance criteria, either. - Consider adding CIs for clang 16 to 19. - Apply concept checking to completion tokens, using the BOOST_ASIO_COMPLETION_TOKEN_FOR macro for C++17 compatibility. - Consider using an inline variable to implement get_error_code_category, instead of a static one. - Place non-documented, non-public functions in the detail namespace. Candidate functions: - client_error_to_string, in error.hpp - client_ec_category, in error.hpp - Auxiliary functions and types implementing properties, in property_types.hpp - to_reason_code, in reason_codes.hpp - Consider making the library compatible with the BOOST_ASIO_USE_TS_EXECUTOR_AS_DEFAULT macro. Although legacy, other libraries (namely a postgresql one) require it. - Consider making the will class a plain struct, instead of a class. This would make it compatible with C++20 designated initializers. - Consider renaming the library and namespace to mqtt5 or mqtt, following what we have for MySQL and Redis. Note that typing boost::async_mqtt5 may be long. - Consider making constexpr global variables (like the ones in reason_codes.hpp) inline constexpr. - Consider enhancing support for Asio handler tracking (as per https://live.boost.org/doc/libs/1_86_0/doc/html/boost_asio/overview/core/ha…) by using the BOOST_ASIO_HANDLER_LOCATION macro. This may mitigate the frustration of users experiencing connectivity problems. - Consider running the thread-safety example under the thread sanitizer. I've found a lot of surprises (and learnt a lot) by doing this. - Consider renaming client_service to something that doesn't include the term "service". When working with Asio, a service usually refers to something inheriting from asio::execution_context::service, allocated once per execution context. This is not the case for client_service, which initially created confusing expectations to me. - Consider replacing the SFINAE clause in authenticator() by a static_assert. Calling authenticator() with something not fulfilling the concept is always an error - the clearer the diagnostic, the better. - Consider whether asio::cancel_after/asio::cancel_at can be used to simplify some of the internal waiting logic. - Consider moving the code snippets shown in the discussion to a C++ file and use Quickbook import statements to include them in the docs. This reduces the possibility of having out-of-sync snippets. - Consider specializing asio::associated_executor, asio::associated_immediate_executor and asio::associated_allocator to implement property propagation in detail::cancellable_handler. 4. Comments on docs. These are not acceptance criteria. - The reference lists is_authenticator (https://spacetime.mireo.com/async-mqtt5/async_mqtt5/ref/is_authenticator.ht…) but it looks like it's in the detail namespace. Either promote it to the public namespace, or hide it from the docs (you can still create a page for the concept even if you don't expose the actual type). - The reference lists the phrase "On immediate completion, invocation of the handler will be performed in a manner equivalent to using boost::asio::post.". This is not true, since you support immediate executors. - Some property types are listed as scalars, when they are really vectors of scalars. This might be confusing. For instance, https://spacetime.mireo.com/async-mqtt5/async_mqtt5/ref/publish_props.html lists subscription_identifier as std::string, when it's actually std::vector<std::string>. Same applies for user_property. - As of Boost 1.86, timeouts should be implemented using asio::cancel_after, rather than by awaitable operators or parallel groups. I suggest replacing the examples on timeouts by a single one using asio::cancel_after. - Type requirements for ExecutionContext (https://spacetime.mireo.com/async-mqtt5/async_mqtt5/ref/ExecutionContext.ht…) are not correct. You can probably just link to Asio's description: https://www.boost.org/doc/libs/1_86_0/doc/html/boost_asio/reference/Executi…. - The multithreaded example recommends the following code to run callbacks though a strand: boost::asio::post( strand, [&client, &strand] { // Considering that the default associated executor of all completion handlers is the strand, // it is not necessary to explicitly bind it to async_run or other async_xxx's handlers. client.async_run(boost::asio::detached); } ); This form of post is not equivalent to asio::post(asio::bind_executor(ex, ...)), and can yield surprising behavior if the token has a bound executor. Furthermore, post might be less efficient than dispatch, and should only be used if a reschedule is required (which is not the case). I'd advise to change the above by: boost::asio::dispatch(boost::asio::bind_executor( strand, [&client, &strand] { // Considering that the default associated executor of all completion handlers is the strand, // it is not necessary to explicitly bind it to async_run or other async_xxx's handlers. client.async_run(boost::asio::detached); } )); - The multi-threaded example uses asio::io_context and a vector of threads. This is error-prone. It can be simplified by using asio::thread_pool, asio::thread_pool::attach and asio::thread_pool::join. - The coroutine examples can be simplified with the latest Asio additions. At the moment, asio::deferred is recommended over asio::use_awaitable for efficiency reasons. With partial tokens, async_xxx(asio::as_tuple(asio::deferred)) can be replaced by async_xxx(asio::as_tuple). - The coroutines examples shouldn't use asio::detached with asio::co_spawn, as this swallows any thrown exceptions. It's better to use [](std::exception_ptr e) { if(e) std::rethrow_exception(e); }, as this propagates exceptions to main. - It's probably better to avoid the unified header in the examples. We should encourage including individual headers, instead, as this is better for compile times. - In https://spacetime.mireo.com/async-mqtt5/async_mqtt5/connection_maintenance.…: should be "the MQTT <protocol>" (missing word). - https://spacetime.mireo.com/async-mqtt5/async_mqtt5/optimising_communicatio…: typo: "simultanious". - https://spacetime.mireo.com/async-mqtt5/async_mqtt5/ref/mqtt_client/operato…: moved-from state probably supports being assigned to, too. - https://spacetime.mireo.com/async-mqtt5/async_mqtt5/ref/mqtt_client/tls_con…: render error in the 1st template parameter. - https://spacetime.mireo.com/async-mqtt5/async_mqtt5/ref/mqtt_client/authent…: render error in the 1st template parameter. - https://spacetime.mireo.com/async-mqtt5/async_mqtt5/ref/authority_path.html: member descriptions are empty. Thanks Ivica for proposing the library. I really hope to see it in Boost in the near future. Regards, Ruben.

2 2

Re: [boost] [async-mqtt5] Review questions
by Ruben Perez 18 Oct '24

18 Oct '24

(CC-ing the list) > > > > I haven't looked at the implementation yet, but I'm assuming that > > owning types are being used for a reason. > > You mean like ASIO buffers? Or vector? To std::move them around? I mean that the current interface is using std::string (owning) as the argument type for message payloads, which probably means that the implementation will std::move the supplied buffer, so the user doesn't need to keep it alive. My question was regarding the use of a character type (like std::string) vs a blob type (like std::vector<std::byte>), more than an owning vs. a non-woning type. Now that you've mentioned it, most Asio-based libraries require the user to keep the message payload alive for the duration of the operation, in an attempt to minimize copying. So I will add this to my list of questions for Ivica: is there a reason why you decided to use an owning type for the message payload? Regards, Ruben.

1 0

[release] Boost 1.87.0 closes for new libraries on 23-October
by Marshall Clow 16 Oct '24

16 Oct '24

As always, the calendar is at: https://www.boost.org/development/index.html — The release managers

1 0

Boost cross-compilation and testing (Linux -> Windows)
by Martin Vejbora 16 Oct '24

16 Oct '24

Hello, we're working on a new target for MinGW compiler, we're intending to have a cross-compiler from Linux Arm64 to Windows Arm64. We want to have Boost library as a benchmark of how complete our C++ compiler is and gradually improve it to support more features. I'm struggling though to get the cross-compilation and subsequent testing working. 1) I'm having troubles to set up cross-building of Boost with MinGW (even standard MinGW from package manager Linux x64 -> Windows x64). I'm getting errors while building Context, Process and Stacktrace modules. (I added to the respective error messages to the end of the email or full logs can be found here: https://github.com/user-attachments/files/17133738/x64_boost_build.log) My build commands: git clone --recursive https://github.com/boostorg/boost.git boost-build cd boost-build git checkout develop git submodule update --init --recursive echo "using gcc : : x86_64-w64-mingw32-g++ ;" > "user-config-x64.jam" ./bootstrap.sh ./b2 --user-config=./user-config-x64.jam --prefix=./boost-x64 --debug-configuration target-os=windows address-model=64 variant=debug install > x64_boost_build.log >From the error messages, it seems like I'm doing something essential wrong as for example Process module tries to build assembler for ELF format and SYSV ABI and not Window's PE format and MS ABI. 2) Subsequently, I didn't have much luck finding resources for cross-testing of Boost. Currently, I'm building and running tests in Ubuntu 22.04 in WSL on Windows machine. In general, this approach seems to work decently, Boost itself and its tests are built on Ubuntu as Windows binaries and when test executables are run, WSL automatically propagates it to run those executables on underlaying Windows. But a lot of tests are failing. I'm gradually investigating them and finding issues like missing dlls because b2 uses LD_LIBRARY_PATH and Windows doesn't understand it. I'm workarounding these issues but it's a slow process, so I wanted to ask, is the cross-testing of Boost library supported, are you aware of some examples where it's being used? Thank you and kind regards, Martin ------------------------------------------------------------------------------- a) Context errors: (similar also for jump_x86_64_sysv_elf_gas.S and ontop_x86_64_sysv_elf_gas.S) gcc.compile.asm bin.v2/libs/context/build/gcc-10/debug/x86_64/link-static/ target-os-windows/threadapi-win32/threading-multi/visibility-hidden/ asm/make_x86_64_sysv_elf_gas.o make_x86_64_sysv_elf_gas.S: Assembler messages: make_x86_64_sysv_elf_gas.S:47: Warning: .type pseudo-op used outside of .def/.endef: ignored. make_x86_64_sysv_elf_gas.S:47: Error: junk at end of line, first unrecognized character is `m' /home/vejby/boost-build/libs/context/src/asm/make_x86_64_sysv_elf_gas.S:157: Warning: .size pseudo-op used outside of .def/.endef: ignored. /home/vejby/boost-build/libs/context/src/asm/make_x86_64_sysv_elf_gas.S:157: Error: junk at end of line, first unrecognized character is `m' /home/vejby/boost-build/libs/context/src/asm/make_x86_64_sysv_elf_gas.S:160: Error: junk at end of line, first unrecognized character is `-' "x86_64-w64-mingw32-g++" -x assembler-with-cpp -m64 -O0 -fno-inline -Wall -g -fvisibility=hidden -DBOOST_ALL_NO_LIB=1 -DBOOST_CONTEXT_NO_LIB=1 -DBOOST_CONTEXT_SOURCE -D_WIN32_WINNT=0x0601 -I"." -I"/home/vejby/boost-build/libs/assert/include" -I"/home/vejby/boost-build/libs/context/include" -I"/home/vejby/boost-build/libs/core/include" -I"/home/vejby/boost-build/libs/move/include" -I"/home/vejby/boost-build/libs/mp11/include" -I"/home/vejby/boost-build/libs/predef/include" -I"/home/vejby/boost-build/libs/smart_ptr/include" -I"/home/vejby/boost-build/libs/throw_exception/include" -I"/home/vejby/boost-build/libs/type_traits/include" -c -o "bin.v2/libs/context/build/gcc-10/debug/x86_64/link-static/target-os-windows/ threadapi-win32/threading-multi/visibility-hidden/asm/make_x86_64_sysv_elf_gas.o" "/home/vejby/boost-build/libs/context/src/asm/make_x86_64_sysv_elf_gas.S" ...failed gcc.compile.asm bin.v2/libs/context/build/gcc-10/debug/x86_64/link-static/target-os-windows/ threadapi-win32/threading-multi/visibility-hidden/asm/make_x86_64_sysv_elf_gas.o... ------------------------------------------------------------------------------- b) Process errors: gcc.compile.c++ bin.v2/libs/process/build/gcc-10/debug/x86_64/ boost.process.fs-boost/link-static/target-os-windows/threadapi-win32/ threading-multi/visibility-hidden/ext/exe.o /home/vejby/boost-build/libs/process/src/ext/exe.cpp: In function ‘boost::filesystem::path boost::process::v2::ext::exe (HANDLE, boost::system::error_code&)’: /home/vejby/boost-build/libs/process/src/ext/exe.cpp:78:9: error: ‘QueryFullProcessImageNameW’ was not declared in this scope 78 | if (QueryFullProcessImageNameW(proc, 0, buffer, &size)) | ^~~~~~~~~~~~~~~~~~~~~~~~~~ "x86_64-w64-mingw32-g++" -fvisibility-inlines-hidden -m64 -O0 -fno-inline -Wall -g -fvisibility=hidden -DBOOST_ALL_NO_LIB=1 -DBOOST_ASIO_NO_DEPRECATED -DBOOST_ATOMIC_STATIC_LINK=1 -DBOOST_FILESYSTEM_NO_LIB=1 -DBOOST_FILESYSTEM_STATIC_LINK=1 -DBOOST_PROCESS_SOURCE=1 -DBOOST_REGEX_NO_LIB=1 -DBOOST_SYSTEM_NO_LIB=1 -DBOOST_SYSTEM_STATIC_LINK=1 -DWIN32_LEAN_AND_MEAN -I"." -I"/home/vejby/boost-build/libs/algorithm/include" -I"/home/vejby/boost-build/libs/assert/include" -I"/home/vejby/boost-build/libs/bind/include" -I"/home/vejby/boost-build/libs/container_hash/include" -I"/home/vejby/boost-build/libs/core/include" -I"/home/vejby/boost-build/libs/describe/include" -I"/home/vejby/boost-build/libs/detail/include" -I"/home/vejby/boost-build/libs/filesystem/include" -I"/home/vejby/boost-build/libs/function/include" -I"/home/vejby/boost-build/libs/function_types/include" -I"/home/vejby/boost-build/libs/fusion/include" -I"/home/vejby/boost-build/libs/iterator/include" -I"/home/vejby/boost-build/libs/move/include" -I"/home/vejby/boost-build/libs/mp11/include" -I"/home/vejby/boost-build/libs/optional/include" -I"/home/vejby/boost-build/libs/predef/include" -I"/home/vejby/boost-build/libs/process/include" -I"/home/vejby/boost-build/libs/regex/include" -I"/home/vejby/boost-build/libs/scope/include" -I"/home/vejby/boost-build/libs/smart_ptr/include" -I"/home/vejby/boost-build/libs/system/include" -I"/home/vejby/boost-build/libs/throw_exception/include" -I"/home/vejby/boost-build/libs/tuple/include" -I"/home/vejby/boost-build/libs/type_index/include" -I"/home/vejby/boost-build/libs/type_traits/include" -I"/home/vejby/boost-build/libs/unordered/include" -I"/home/vejby/boost-build/libs/variant2/include" -I"/home/vejby/boost-build/libs/winapi/include" -c -o "bin.v2/libs/process/build/gcc-10/debug/x86_64/boost.process.fs-boost/ link-static/target-os-windows/threadapi-win32/threading-multi/ visibility-hidden/ext/exe.o" "/home/vejby/boost-build/libs/process/src/ext/exe.cpp" ...failed gcc.compile.c++ bin.v2/libs/process/build/gcc-10/debug/x86_64/boost.process.fs-boost/ link-static/target-os-windows/threadapi-win32/threading-multi/ visibility-hidden/ext/exe.o... ------------------------------------------------------------------------------- gcc.compile.c++ bin.v2/libs/process/build/gcc-10/debug/x86_64/ boost.process.fs-boost/link-static/target-os-windows/threadapi-win32/ threading-multi/visibility-hidden/windows/default_launcher.o In file included from /home/vejby/boost-build/libs/process/src/windows/ default_launcher.cpp:16: ./boost/process/v2/windows/default_launcher.hpp:220:3: error: ‘STARTUPINFOEXW’ does not name a type; did you mean ‘STARTUPINFOW’? 220 | STARTUPINFOEXW startup_info{{sizeof(STARTUPINFOEXW), nullptr, nullptr, nullptr, | ^~~~~~~~~~~~~~ | STARTUPINFOW ./boost/process/v2/windows/default_launcher.hpp: In member function ‘boost::process::v2::windows::default_launcher::enable_init <Executor, Inits ...> boost::process::v2::windows::default_launcher:: operator()(Executor, boost::system::error_code&, const typename std::enable_if<( boost::asio::execution::is_executor<T>::value || boost::asio::is_executor<Executor>::value ), boost::filesystem::path>::type&, Args&&, Inits&& ...)’: ./boost/process/v2/windows/default_launcher.hpp:312:10: error: ‘startup_info’ was not declared in this scope 312 | &startup_info.StartupInfo, | ^~~~~~~~~~~~ /home/vejby/boost-build/libs/process/src/windows/default_launcher.cpp: In static member function ‘static std::size_t boost::process::v2::windows:: default_launcher::escape_argv_string(wchar_t*, std::size_t, boost::basic_string_view<wchar_t, std::char_traits<wchar_t> >)’: /home/vejby/boost-build/libs/process/src/windows/default_launcher.cpp:64:16: warning: unused variable ‘end’ [-Wunused-variable] 64 | const auto end = itr + sz; | ^~~ "x86_64-w64-mingw32-g++" -fvisibility-inlines-hidden -m64 -O0 -fno-inline -Wall -g -fvisibility=hidden -DBOOST_ALL_NO_LIB=1 -DBOOST_ASIO_NO_DEPRECATED -DBOOST_ATOMIC_STATIC_LINK=1 -DBOOST_FILESYSTEM_NO_LIB=1 -DBOOST_FILESYSTEM_STATIC_LINK=1 -DBOOST_PROCESS_SOURCE=1 -DBOOST_REGEX_NO_LIB=1 -DBOOST_SYSTEM_NO_LIB=1 -DBOOST_SYSTEM_STATIC_LINK=1 -DWIN32_LEAN_AND_MEAN -I"." -I"/home/vejby/boost-build/libs/algorithm/include" -I"/home/vejby/boost-build/libs/assert/include" -I"/home/vejby/boost-build/libs/bind/include" -I"/home/vejby/boost-build/libs/container_hash/include" -I"/home/vejby/boost-build/libs/core/include" -I"/home/vejby/boost-build/libs/describe/include" -I"/home/vejby/boost-build/libs/detail/include" -I"/home/vejby/boost-build/libs/filesystem/include" -I"/home/vejby/boost-build/libs/function/include" -I"/home/vejby/boost-build/libs/function_types/include" -I"/home/vejby/boost-build/libs/fusion/include" -I"/home/vejby/boost-build/libs/iterator/include" -I"/home/vejby/boost-build/libs/move/include" -I"/home/vejby/boost-build/libs/mp11/include" -I"/home/vejby/boost-build/libs/optional/include" -I"/home/vejby/boost-build/libs/predef/include" -I"/home/vejby/boost-build/libs/process/include" -I"/home/vejby/boost-build/libs/regex/include" -I"/home/vejby/boost-build/libs/scope/include" -I"/home/vejby/boost-build/libs/smart_ptr/include" -I"/home/vejby/boost-build/libs/system/include" -I"/home/vejby/boost-build/libs/throw_exception/include" -I"/home/vejby/boost-build/libs/tuple/include" -I"/home/vejby/boost-build/libs/type_index/include" -I"/home/vejby/boost-build/libs/type_traits/include" -I"/home/vejby/boost-build/libs/unordered/include" -I"/home/vejby/boost-build/libs/variant2/include" -I"/home/vejby/boost-build/libs/winapi/include" -c -o "bin.v2/libs/process/build/gcc-10/debug/x86_64/boost.process.fs-boost/ link-static/target-os-windows/threadapi-win32/threading-multi/ visibility-hidden/windows/default_launcher.o" "/home/vejby/boost-build/libs/process/src/windows/default_launcher.cpp" ...failed gcc.compile.c++ bin.v2/libs/process/build/gcc-10/debug/x86_64/boost.process.fs-boost/ link-static/target-os-windows/threadapi-win32/threading-multi/ visibility-hidden/windows/default_launcher.o... ------------------------------------------------------------------------------- gcc.compile.c++ bin.v2/libs/process/build/gcc-10/debug/x86_64 boost.process.fs-boost/link-static/target-os-windows/threadapi-win32/ threading-multi/visibility-hidden/environment.o In file included from ./boost/process/v2/default_launcher.hpp:17, from /home/vejby/boost-build/libs/process/src/environment.cpp:13: ./boost/process/v2/windows/default_launcher.hpp:220:3: error: ‘STARTUPINFOEXW’ does not name a type; did you mean ‘STARTUPINFOW’? 220 | STARTUPINFOEXW startup_info{{sizeof(STARTUPINFOEXW), nullptr, nullptr, nullptr, | ^~~~~~~~~~~~~~ | STARTUPINFOW ./boost/process/v2/windows/default_launcher.hpp: In member function ‘boost::process::v2::windows::default_launcher::enable_init<Executor, Inits ...> boost::process::v2::windows::default_launcher::operator()(Executor, boost::system::error_code&, const typename std::enable_if<( boost::asio::execution::is_executor<T>::value || boost::asio::is_executor<Executor>::value ), boost::filesystem::path>::type&, Args&&, Inits&& ...)’: ./boost/process/v2/windows/default_launcher.hpp:312:10: error: ‘startup_info’ was not declared in this scope 312 | &startup_info.StartupInfo, | ^~~~~~~~~~~~ "x86_64-w64-mingw32-g++" -fvisibility-inlines-hidden -m64 -O0 -fno-inline -Wall -g -fvisibility=hidden -DBOOST_ALL_NO_LIB=1 -DBOOST_ASIO_NO_DEPRECATED -DBOOST_ATOMIC_STATIC_LINK=1 -DBOOST_FILESYSTEM_NO_LIB=1 -DBOOST_FILESYSTEM_STATIC_LINK=1 -DBOOST_PROCESS_SOURCE=1 -DBOOST_REGEX_NO_LIB=1 -DBOOST_SYSTEM_NO_LIB=1 -DBOOST_SYSTEM_STATIC_LINK=1 -DWIN32_LEAN_AND_MEAN -I"." -I"/home/vejby/boost-build/libs/algorithm/include" -I"/home/vejby/boost-build/libs/assert/include" -I"/home/vejby/boost-build/libs/bind/include" -I"/home/vejby/boost-build/libs/container_hash/include" -I"/home/vejby/boost-build/libs/core/include" -I"/home/vejby/boost-build/libs/describe/include" -I"/home/vejby/boost-build/libs/detail/include" -I"/home/vejby/boost-build/libs/filesystem/include" -I"/home/vejby/boost-build/libs/function/include" -I"/home/vejby/boost-build/libs/function_types/include" -I"/home/vejby/boost-build/libs/fusion/include" -I"/home/vejby/boost-build/libs/iterator/include" -I"/home/vejby/boost-build/libs/move/include" -I"/home/vejby/boost-build/libs/mp11/include" -I"/home/vejby/boost-build/libs/optional/include" -I"/home/vejby/boost-build/libs/predef/include" -I"/home/vejby/boost-build/libs/process/include" -I"/home/vejby/boost-build/libs/regex/include" -I"/home/vejby/boost-build/libs/scope/include" -I"/home/vejby/boost-build/libs/smart_ptr/include" -I"/home/vejby/boost-build/libs/system/include" -I"/home/vejby/boost-build/libs/throw_exception/include" -I"/home/vejby/boost-build/libs/tuple/include" -I"/home/vejby/boost-build/libs/type_index/include" -I"/home/vejby/boost-build/libs/type_traits/include" -I"/home/vejby/boost-build/libs/unordered/include" -I"/home/vejby/boost-build/libs/variant2/include" -I"/home/vejby/boost-build/libs/winapi/include" -c -o "bin.v2/libs/process/build/gcc-10/debug/x86_64/boost.process.fs-boost/ link-static/target-os-windows/threadapi-win32/threading-multi/ visibility-hidden/environment.o" "/home/vejby/boost-build/libs/process/src/environment.cpp" ...failed gcc.compile.c++ bin.v2/libs/process/build/gcc-10/debug/x86_64/boost.process.fs-boost/ link-static/target-os-windows/threadapi-win32/threading-multi/ visibility-hidden/environment.o... ------------------------------------------------------------------------------- c) Stacktrace error: gcc.compile.c++ bin.v2/libs/stacktrace/build/gcc-10/debug/x86_64/link-static/ target-os-windows/threadapi-win32/threading-multi/visibility-hidden/ from_exception.o /home/vejby/boost-build/libs/stacktrace/build/../src/from_exception.cpp:161:10: fatal error: dlfcn.h: No such file or directory 161 | #include <dlfcn.h> | ^~~~~~~~~ compilation terminated. "x86_64-w64-mingw32-g++" -fvisibility-inlines-hidden -m64 -O0 -fno-inline -Wall -g -fvisibility=hidden -DBOOST_ALL_NO_LIB=1 -I"." -I"/home/vejby/boost-build/libs/assert/include" -I"/home/vejby/boost-build/libs/container_hash/include" -I"/home/vejby/boost-build/libs/core/include" -I"/home/vejby/boost-build/libs/describe/include" -I"/home/vejby/boost-build/libs/mp11/include" -I"/home/vejby/boost-build/libs/predef/include" -I"/home/vejby/boost-build/libs/stacktrace/include" -I"/home/vejby/boost-build/libs/throw_exception/include" -I"/home/vejby/boost-build/libs/winapi/include" -c -o "bin.v2/libs/stacktrace/build/gcc-10/debug/x86_64/link-static/ target-os-windows/threadapi-win32/threading-multi/visibility-hidden/ from_exception.o" "/home/vejby/boost-build/libs/stacktrace/build/../src/from_exception.cpp" ...failed gcc.compile.c++ bin.v2/libs/stacktrace/build/gcc-10/debug/x86_64/link-static/target-os-windows/ threadapi-win32/threading-multi/visibility-hidden/from_exception.o...

3 4

[Boost][BGL] What are the correct vertex/edge index types?
by hermann＠stamm-wilbrandt.de 15 Oct '24

15 Oct '24

First I looked in graph/test. Most times int is used there, only once std::size_t: property< edge_index_t, int > Next I looked into graph/example, same picture there. Ok, I read that example and test might contain stuff that would not go into BGL code. So I looked into graph/include/boost/graph: pi@raspberrypi5:~/graph/include/boost/graph $ grep edge_index_t *.hpp | grep size_t directed_graph.hpp: typedef std::size_t edge_index_type; undirected_graph.hpp: typedef std::size_t edge_index_type; pi@raspberrypi5:~/graph/include/boost/graph $ grep edge_index_t *.hpp | grep unsigned directed_graph.hpp: typedef property< edge_index_t, unsigned, edge_property_type > undirected_graph.hpp: typedef property< edge_index_t, unsigned, edge_property_type > pi@raspberrypi5:~/graph/include/boost/graph $ grep edge_index_t *.hpp | grep int graphviz.hpp: property<edge_index_t, int> > pi@raspberrypi5:~/graph/include/boost/graph $ Only graphviz.hpp uses int. But directed and undirected graph use std::size_t as well as unsigned. There are systems when unsigned is smaller than std::size_t: https://en.cppreference.com/w/cpp/types/size_t 1) Shouldn't at least directed_graph.hpp and undirected_graph.hpp make consistent use of std::size_t then? 2) Shouldn't examples and tests be corrected, as their overly use of int for edge and vertex index types is misleading? Regards, Hermann.

2 1

deprecated: MPL, foreach, typeof, ratio, chrono, assign, more?
by Vinnie Falco 12 Oct '24

12 Oct '24

Should one or more of these libraries be marked as "deprecated" in their corresponding meta/libraries.json? Array Assign Chrono Compatibility compressed_pair enable_if ForEach functional mem_fn move MPL Ratio ResultOf Typeof The new website could use this information to annotate the library. We could add a "reason" field to libraries.json which is displayed on the site. The website could have a checkbox, "hide deprecated", enabled by default. We could show the reason for the deprecation. For example, that mp11 is a more modern and functional version of MPL. Or that ForEach is now a C++ language feature. The authors and maintainers of those libraries would need to opt-in to this, although we could have someone work up pull requests for some or all of those libraries. There might be more libraries that belong on the list, feel free to add. Another idea we might consider is to add a preprocessor deprecation warning, unless the user opts-in by defining BOOST_ALLOW_DEPRECATED or something. Before we do that though, we should ensure that no non-deprecated Boost libraries are using the above libraries. Thanks

20 51

Do Tools Need Formal Reviews?
by Vinnie Falco 10 Oct '24

10 Oct '24

Traditionally, tools used by authors and maintainers are quietly integrated with oversight from owners and release managers. Examples include saxon-he and docca (https://github.com/boostorg/docca) Recently there have been noises made expressing the desire for the formal review process to be applied to tools as well. The purpose of this post is to explain why this is a bad idea. There are two kinds of tools. External tools, brought into use by the project through the scripts which create the release, and internal tools which are in repositories added to the superproject. An example of an external tool is asciidoctor: https://asciidoctor.org/ This was quietly added and the command line tool is required to be installed in order to build a Boost release, as libraries such as Boost.mp11 or Boost.Unordered need it for producing their documentation. The Asciidoctor author provides the installation package and provides all support. The only documentation requirement for Boost libraries is that they render into HTML and that "b2 doc" works. A formal review to adopt "asciidoctor" as an available external tool could result in REJECT. This serves no useful purpose other than to make things more difficult for the author or maintainer. They can still use asciidoctor but would have to do it locally and commit the resulting HTML output to the repository, as the tool would not be available to the release process. This is objectively worse for everyone. An example of an internal tool is BoostLook: https://github.com/boostorg/boostlook This is a set of CSS files and Ruby scripts used by some libraries to style their Asciidoctor documentation. This was quietly added to the superproject as the release will need it for some of the libraries to build. Discussion with owners happened beforehand; the files for this tool were originally in the website-v2-docs repo (https://github.com/boostorg/website-v2-docs) but the objection was made (rightly so) that the website-v2-docs repo was too large to add to the superproject. Thus the files were put into their own small repository. A formal review to adopt BoostLook as an internal tool could result in a REJECT outcome. This serves no useful purpose other than to make things more difficult for maintainers. They would manually inline the boostlook files in their repository and be responsible for keeping it up to date (submodules in libraries are intentionally not cloned by the release script). Tools are not user-facing (where "user" is defined as a Boost user and not an author or maintainer). I've seen a lot of intellectual gymnastics trying to justify why tools are the equal of libraries but they fail in light of an obvious fact: tools no longer in use can be removed from the superproject without a tsunami of mailing list protest. It is true that tools which Boost end-users find useful can be adopted, but they do not come with the same promise of forever support the way that libraries do. They are only supported to the extent to which the Boost libraries need them. My maybe-unpopular opinion: b2 was correct to move to an independent repository, as this can come with implied lifetime support. There's a recurring theme: tools are not libraries, despite Robert Ramey's sincere efforts to formally review them as such. A tool is an administrative construct designed to facilitate the efforts of authors and maintainers when they wish to make use of the tool in more than one library. The use of the tool is still possible in a Boost library, without the tool becoming part of the superproject, yet with more effort and opportunity for mistakes. It is for this reason that we do not use the formal review process for tools, as rejecting a tool has only disadvantages for existing libraries. The very last thing we need to do now is to make things harder for authors and maintainers. An argument used to justify a formal review is that the resulting feedback can improve the tool. I agree that feedback is generally helpful, this is true even if there is no formal review. That is, there is no requirement for a formal review to be ongoing for someone to provide feedback. Just provide the feedback. Tools are boring, and unlikely to attract a significant number of review responses. Formal reviews of proposed internal tools which receive a very small number of reviewers do not signal strong consensus and I believe harm morale. The informal process used for oversight on the internal and external tools Boost uses to produce its releases has worked well, and no convincing rationale has been put forth for why it should change. We should not invoke the formal review process for tools. Thanks

8 11

Who can fix CI ?
by hermann＠stamm-wilbrandt.de 09 Oct '24

09 Oct '24

5 days ago I created my first PR: "new planar_vertex_six_coloring() algorithm with examples, tests and doc" https://github.com/boostorg/graph/pull/387 CI helped me to fix things I was responsible for. But after that CI still fails in code I am not responsible for. From release notes: https://www.boost.org/users/history/version_1_86_0.html "...Graph: Major update: C++14 is the new minimum standard; this was partly dictated by dependencies (at least to C++11) and partly by choice. If you require support for an older standard, please contact the maintainer. ..." Somebody (who?) forgot to tell CI that minimum requirement. Example error caused by this: gcc.compile.c++ ../../../bin.v2/libs/graph/test/gursoy_atun_layout_test.test/gcc-5/debug/x86_64/cxxstd-11-iso/threading-multi/visibility-hidden/gursoy_atun_layout_test.o In file included from ../../../boost/math/constants/constants.hpp:11:0, from ../../../boost/graph/topology.hpp:16, from ../../../boost/graph/gursoy_atun_layout.hpp:34, from gursoy_atun_layout_test.cpp:10: ../../../boost/math/tools/config.hpp:28:6: warning: #warning "Boost.Math requires C++14" [-Wcpp] # warning "Boost.Math requires C++14" ^ In file included from ../../../boost/math/tools/mp.hpp:15:0, from ../../../boost/math/policies/policy.hpp:11, from ../../../boost/math/constants/constants.hpp:16, from ../../../boost/graph/topology.hpp:16, from ../../../boost/graph/gursoy_atun_layout.hpp:34, from gursoy_atun_layout_test.cpp:10: ../../../boost/math/tools/type_traits.hpp:208:12: error: 'std::is_final' has not been declared using std::is_final; Since this is my first PR, will there be someone helping me in PR 387? Who owns CI? Can issues be created against CI? Or do I understand this completely wrong? Regards, Hermann.

2 2

(no subject)
by Christophe Henry 08 Oct '24

08 Oct '24

> Should one or more of these libraries be marked as "deprecated" in their > corresponding meta/libraries.json? > > Array > Assign > Chrono > Compatibility > compressed_pair > enable_if > ForEach > functional > mem_fn > move > MPL > Ratio > ResultOf > Typeof Yes for marking old libraries as obsolete, as it does not convey a "might be removed" tag. No for marking as deprecated for this reason. Yes for hiding obsolete libraries by default. Strong no for ever even thinking of removing a Boost library from 1.x. Strong no for marking as obsolete libraries which are using obsolete libraries in the implementation. This one would force me to drop parts of MSM which might be used in production code and I strongly oppose the idea. Christophe

7 20

Scheduled review of Decimal library
by Mateusz Loskot 08 Oct '24

08 Oct '24

Folks, On behalf of the Review Wizards Team, formal review of proposed Decimal library has now been scheduled: - https://github.com/boostorg/website/pull/878 The review details should be soon displayed on the website - https://www.boost.org/community/review_schedule.html Best regards, Mateusz Loskot

4 6

[context] Build error with context-impl
by Tim Haines 08 Oct '24

08 Oct '24

git -c advice.detachedHead=false clone --branch develop --single-branch --depth 1 https://github.com/boostorg/boost.git git -c advice.detachedHead=false submodule update --init --recursive ./bootstrap.sh --with-toolset=gcc --with-libraries=context ./b2 -d+2 --debug-configuration --debug-building --debug-generator headers context-impl=fcontext toolset=gcc cxxstd=20 notice: found boost-build.jam at /boostorg/boost-build.jam notice: loading B2 from /boostorg/tools/build/src/build-system.jam notice: Searching <redacted> for site-config configuration file 'site-config.jam'. notice: Configuration file 'site-config.jam' not found in <redacted>. notice: Searching <redacted> for user-config configuration file 'user-config.jam'. notice: Configuration file 'user-config.jam' not found in <redacted>. notice: Searching '.' for project-config configuration file 'project-config.jam'. notice: Loading project-config configuration file 'project-config.jam' from '.'. notice: will use 'g++' for gcc, condition <toolset>gcc-11 notice: using gcc libraries :: <toolset>gcc-11 :: /usr/bin /usr/lib /usr/lib32 /usr/lib64 notice: using gcc archiver :: <toolset>gcc-11 :: /usr/bin/ar warning: toolset gcc initialization: can not find tool windres warning: initialized from project-config.jam:12 notice: using rc compiler :: <toolset>gcc-11 :: /usr/bin/as /boostorg/tools/build/src/build/feature.jam:327: in validate-feature from module feature error: unknown feature "<context-impl>" /boostorg/tools/build/src/build/feature.jam:361: in expand-subfeatures-aux from module feature /boostorg/tools/build/src/build/feature.jam:422: in feature.expand-subfeatures from module feature /boostorg/tools/build/src/build/build-request.jam:20: in apply-to-property-set from module build-request (builtin):-1: in sequence.transform from module sequence /boostorg/tools/build/src/build/build-request.jam:32: in build-request.expand-no-defaults from module build-request /boostorg/tools/build/src/build-system.jam:778: in module scope from module build-system The feature is present: grep -A5 -n "feature.feature context-impl" libs/context/build/Jamfile.v2 52:feature.feature context-impl 53- : fcontext 54- ucontext 55- winfib 56- : propagated 57- composite I'm not familiar with the Jam DSL, so I'm not sure how to debug this further. Any advice is very welcome. Thanks. - Tim

2 2

[Boost] runtime+memory evaluation of 6 BGL planar graph algorithms
by hermann＠stamm-wilbrandt.de 06 Oct '24

06 Oct '24

Half a year ago I copied together Boost examples making use of: boost/graph/make_connected.hpp boost/graph/make_biconnected_planar.hpp boost/graph/make_maximal_planar.hpp boost/graph/boyer_myrvold_planar_test.hpp boost/graph/planar_canonical_ordering.hpp boost/graph/chrobak_payne_drawing.hpp I added "read_leda_graph()" for processing graph files. And added code to write a graphiviz file from the generated straight line drawing. Use of "layout=neato" with fixated vertex coordinates with exclamation mark (pos="3,2!") misuse GraphViz to just draw the BGL determined straight line drawing. I did evaluation on random maximal planar graphs with 10,000 up to 100 million vertices in 10x steps. In 1993 I wrote a technical report on how to create maximal planar random graphs. I published the 1994 code two years ago (self written graph lib, not LEDA nor Boost): https://github.com/Hermann-SW/randomgraph All details of the evaluation including runtime table in this "straight_line_graphviz.cpp" gist comment: https://gist.github.com/Hermann-SW/99d151a273d290ee0d843c79b2da26a8?permali… Total runtime factors are 13.5x and 20.9x between 1, 10 and 100 million vertex graphs. Since the input graphs were maximal planar, the algorithms make_connected / make_biconnected_planar and make_maximal_planar did not have much to do. The resident RAM usage is perfectly linear, 2.8 / 28.1 / 281.4 GB for 1 / 10 / 100 million vertices. 100 million vertices, 300 million edges, edge property, planar ordering, planar straight line drawing and 8 byte storage for numbers on 64bit OS cause a factor of 2800 comparing resident RAM used with number of vertices. Regards, Hermann.

1 0

Scheduled review of MQTT library
by Mateusz Loskot 06 Oct '24

06 Oct '24

Folks, On behalf of the Review Wizards Team, formal review of proposed MQTT library has now been scheduled: - https://github.com/boostorg/website/pull/877 The review details should be soon displayed on the website - https://www.boost.org/community/review_schedule.html Best regards, Mateusz Loskot

2 4

[optional] Feedback on the range interface for Boost.Optional
by Andrzej Krzemienski 05 Oct '24

05 Oct '24

Hi Everyone, I have just recorded the following message in the Mailing List. sob., 14 wrz 2024 o 02:44 Alan de Freitas via Boost <boost(a)lists.boost.org> napisał(a): > - As people seem to imply, the WG21 issue goes way beyond the motivation > behind the proposals or the difficulty behind the Boost review process. Not > all Boost libraries are intended to go through WG21. Not all WG21 proposals > would make good Boost libraries (like begin/end iterators for > std::optional). We are in the process of implementing the range interface for Boost.Optional, as proposed in P3168R2 <https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p3168r2.html> and to the extent possible in C++11. I would like to hear opinions from the people in this list, on if and why this would be a bad idea. Regards, &rzej;

9 18

[Boost][BGL] "is_straight_line_drawing()" is buggy for large graphs
by hermann＠stamm-wilbrandt.de 05 Oct '24

05 Oct '24

A while back I combined all BGL planarity functions (make_"connected / biconnected_planar / maximal_planar" + straight_line_drawing) prepended with "read_leda_graph()" and writing GraphViz output. The Graphviz output uses neato engine because that allows for fixed vertex coordinates with exclamation mark: 2 [pos="3,2!" label="2"] So GraphViz is just misused to display BGL straight line drawing Recently I enhanced it to time each relevant BGL function call in order to verify linear runtime as well as to investigate RAM usage. In 1993 I created a technical report about creation of random maximal planar graphs and published the code 2 years ago: https://gist.github.com/Hermann-SW/99d151a273d290ee0d843c79b2da26a8 I created maximal planar randomgraphs on 10,000, 100,000, 1million and 10million vertices, and used them as input for above timing code. All was fine until and including 1million vertex graph. But for 10million vertex graph final "is_straight_line_drawing()" incorrectly asserted: hermann@7950x:~$ randomgraph/randomgraph 10000000 -t maximal_planar -o 10000000.u ------------------------------------- malloc: 18 malloc-free: 0 hermann@7950x:~$ time ./straight_line_graphviz 10000000.u t read_leda_graph(g, argv[1]); 9.63147 make_connected(g); 1.82002 assert(boyer_myrvold_planarity_test(boyer_myrvold_params::graph = g, boyer_myrvold_params::embedding = &embedding2[0])); 73.5683 make_biconnected_planar(g, &embedding2[0]); 25.9196 assert(boyer_myrvold_planarity_test(boyer_myrvold_params::graph = g, boyer_myrvold_params::embedding = &embedding2[0])); 88.7905 make_maximal_planar(g, &embedding2[0]); 42.7211 assert(boyer_myrvold_planarity_test(boyer_myrvold_params::graph = g, boyer_myrvold_params::embedding = &embedding2[0])); 96.7233 assert(boyer_myrvold_planarity_test(boyer_myrvold_params::graph = g, boyer_myrvold_params::embedding = embedding)); 68.5428 planar_canonical_ordering(g, embedding, std::back_inserter(ordering)); 24.2465 chrobak_payne_straight_line_drawing( g, embedding, ordering.begin(), ordering.end(), straight_line_drawing); 4.49772 assert(is_straight_line_drawing(g, straight_line_drawing)); a.out: straight_line.cpp:163: int main(int, char**): Assertion `is_straight_line_drawing(g, straight_line_drawing)' failed. Aborted (core dumped) real 7m25,836s user 7m15,357s sys 0m10,356s hermann@7950x:~$ I added code into "graph/include/boost/graph/is_straight_line_drawing.hpp" to write the coordinates of the two edges that intersect: hermann@7950x:~$ cat intersect.txt a 4143438 86426 4064945 7932 4064944 7931 4143438 86426 hermann@7950x:~$ As you can see, both edges share vertex at coordinate "4143438,86426", but they do not intersect. Until that point in code the coordinates are std::size_t. But the called function uses double, causing false report: inline bool intersects(double x1, double y1, double x2, double y2, double a1, double b1, double a2, double b2, double epsilon = 0.000001) { I played with different epsilon values including 0, but the valid straight line drawing was always stated to be wrong. There are several algorithms for segment intersection with integer coordinates that don't need division and are correct for integer coordinates that are result of chrobak_payne_straight_line_drawing( g, embedding, ordering.begin(), ordering.end(), straight_line_drawing); https://en.wikipedia.org/wiki/Line%E2%80%93line_intersection#Given_two_poin… or https://www.dcs.gla.ac.uk/~pat/52233/slides/Geometry1x1.pdf#page=4 1) I want to create a BGL issue on this, is that OK? At least the doc does not state any limit on graph sizes: https://www.boost.org/doc/libs/1_86_0/libs/graph/doc/is_straight_line_drawi… 2) I want to create a pull request with new implementation for "intersects()" with integer coordinates. 2 days ago I created pull requests with 7 commits ahead on new "planar_vertex_six_coloring()": https://github.com/boostorg/graph/pull/387 Do I have to wait until that pull request was decided on? Or can I submit separate pull request not interfering with that request on my graph fork? Regards, Hermann.

2 7

Boost.Decimal Seeking Endorsment
by Matt Borland 05 Oct '24

05 Oct '24

Hello, Chris Kormanyos and I are seeking endorsement for our library proposal, Decimal (https://github.com/cppalliance/decimal) What is Decimal? It is an implementation of IEEE 754 and TR 24733[3][5], along with extensions to both. We provide three IEEE 754 compliant types: decimal32, decimal64, and decimal128, as specified in both documents. Since announcing the beta in the first half of the year, we have added three similar but non-compliant types: decimal32_fast, decimal64_fast, and decimal128_fast. These types perform all operations faster than the compliant types, with identical numerical results, at the cost of extra space. We also provide implementations of the majority of the STL as it apply to numerical types. The library is header-only, has no dependencies, and only requires C++14. Why should we have this in Boost? Decimal Floating Point types were standardized in IEEE 754 in the 2008 revision, but it has not been standardized in C++. We believe this library can serve as a reference implementation. An existing alternative would be one of the authors of the IEEE 754 standard helped write libdfp[4]. This is also available in C with GCC as _Decimal32, _Decimal64, and _Decimal128 [1]. We bring these to C++ with similar or better performance. We also bring interoperability with the STL which is missing in the aforementioned libraries. Since the announcement of our beta in the spring we have improved correctness, performance, and gained users. We added the fast types after conversation with Glen Fernandes, and bit conversions for both encodings of the types [2]. I am aware of at least one US-based trading firm using this library in production so the library is out in the field making money today. Should the library be endorsed John Maddock has graciously offered to be our review manager, and are targeting a post-holiday review period in mid-January 2025. Feel free to ask any questions, and open issues prior to the review period. Matt [1] https://gcc.gnu.org/onlinedocs/gcc/Decimal-Float.html [2] https://cppalliance.org/decimal/decimal.html#conversions [3] https://www.open-std.org/JTC1/SC22/WG21/docs/papers/2009/n2849.pdf [4] https://github.com/libdfp/libdfp [5] https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3871.html

3 4

Scheduled review of SQLite library
by Mateusz Loskot 05 Oct '24

05 Oct '24

Folks, On behalf of the Review Wizards Team, formal review of proposed SQLite library has now been scheduled: - https://github.com/boostorg/website/pull/877 The review details should be soon displayed on the website - https://www.boost.org/community/review_schedule.html Best regards, Mateusz Loskot

1 0

Boost.Parser need final approval
by Zach Laine 04 Oct '24

04 Oct '24

I've *finally* gotten back around to making Boost.Parser properly ready for bringing into the next Boost release. Marshall suggested I post here to make sure that people who participated in the review have a chance to check that the notes from the review all got fixed/implemented. So, this is that email. Please have a look if you get the chance. The issue tracker for the github project is down to 8 items, all of which are nice-to-haves. All the issues raised during the review were captured in the issues list, and taken care of. Zach

3 2

Two mqtt libraries
by Robert Ramey 03 Oct '24

03 Oct '24

I've been contacted by my friend and sometime collaborator Takatoshi Kondo regarding his submission of a boost library: https://github.com/redboltz/async_mqtt. It has received two endorsements. He has asked me to be review manager and I'm inclined to accept this request as he was very helpful to me during the refinement of the boost serialization library. There is also mqtt client library that is proposed to the Boost. https://github.com/mireo/async-mqtt5 It also has endorsements and a review manager. A cursory examination of the git hub pages suggest considerable overlap between the two submissions. In general, boost has discouraged the acceptance of multiple libraries with this much overlap - and for good reason. An accepted library often becomes the canonical implementation in large parts of the C++ world. Having two high quality libraries that do almost the same thing is not where we would like to be. I would like to propose that we review both libraries simultaneously in order to try to reach a consensus as to which, if either we want to accept. I know this is a difficult task, but I think it is important that we do this. It's going to be tough to reject a well written library because a better one has been accepted. But it would be worse to reject a well written library merely because another one was submitted first. Normally I don't participate as a review manager as I'm pretty bogged down in Boost stuff as it is. But I'm willing to make an exception in this case due to the importance of this case and my strong personal ties to Takatoshi. BTW - who is the review wizard these days? I presume that he will be the one making the decision about this. Robert Ramey

10 17

std::multiset functionality support in boost interprocess headers
by Murali Kishore 30 Sep '24

30 Sep '24

Hi all, I see multiset is not present in boost interprocess, so I tried to use a "set" with a customized comparator to achieve multiset functionality. sample code: struct set_comparator { bool operator()(const int& a, const int& b) const { return a < b; // if change a <= b then seeing an errror } }; bip::shared_memory_object::remove("SHM"); bip::managed_shared_memory segment(bip::open_or_create, "SHM", 2047*1024*1024); typedef bip::allocator<int, bip::managed_shared_memory::segment_manager> ShmemAllocator; typedef bip::set<int, set_comparator, ShmemAllocator> ShmemSet; segment.destroy<ShmemSet>("MySet"); ShmemSet *sample1 = segment.construct<ShmemSet>("MySet")(set_comparator(), segment.get_segment_manager()); std::cout << "Insert in shared set:" << std::endl; sample1->insert(40); std::cout << "Insert in shared set:" << std::endl; sample1->insert(40); // Crashing here sample1->insert(40); sample1->insert(40); sample1->insert(20); sample1->insert(20); sample1->insert(20); sample1->insert(20); sample1->insert(20); when i try duplicate insertion, seeing following error, /usr/include/boost/intrusive/bstree.hpp:1331: boost::intrusive::bstree_impl<ValueTraits, VoidOrKeyOfValue, VoidOrKeyComp, SizeType, ConstantTimeSize, AlgoType, HeaderHolder>::iterator boost::intrusive::bstree_impl<ValueTraits, VoidOrKeyOfValue, VoidOrKeyComp, SizeType, ConstantTimeSize, AlgoType, HeaderHolder>::insert_unique_commit(boost::intrusive::bstree_impl<ValueTraits, VoidOrKeyOfValue, VoidOrKeyComp, SizeType, ConstantTimeSize, AlgoType, HeaderHolder>::reference, const insert_commit_data&) [with ValueTraits = boost::intrusive::bhtraits<boost::container::dtl::tree_node<int, boost::interprocess::offset_ptr<void>, boost::container::red_black_tree, true>, boost::intrusive::rbtree_node_traits<boost::interprocess::offset_ptr<void>, true>, boost::intrusive::normal_link, boost::intrusive::dft_tag, 3>; VoidOrKeyOfValue = void; VoidOrKeyComp = boost::container::value_to_node_compare<boost::container::dtl::tree_node<int, boost::interprocess::offset_ptr<void>, boost::container::red_black_tree, true>, boost::intrusive::tree_value_compare<boost::interprocess::offset_ptr<int, long int, long unsigned int, 0>, main()::set_comparator, boost::move_detail::identity<int>, bool, true>, bool>; SizeType = long unsigned int; bool ConstantTimeSize = true; boost::intrusive::algo_types AlgoType = boost::intrusive::RbTreeAlgorithms; HeaderHolder = void; boost::intrusive::bstree_impl<ValueTraits, VoidOrKeyOfValue, VoidOrKeyComp, SizeType, ConstantTimeSize, AlgoType, HeaderHolder>::iterator = boost::intrusive::tree_iterator<boost::intrusive::bhtraits<boost::container::dtl::tree_node<int, boost::interprocess::offset_ptr<void>, boost::container::red_black_tree, true>, boost::intrusive::rbtree_node_traits<boost::interprocess::offset_ptr<void>, true>, boost::intrusive::normal_link, boost::intrusive::dft_tag, 3>, false>; boost::intrusive::bstree_impl<ValueTraits, VoidOrKeyOfValue, VoidOrKeyComp, SizeType, ConstantTimeSize, AlgoType, HeaderHolder>::reference = boost::container::dtl::tree_node<int, boost::interprocess::offset_ptr<void>, boost::container::red_black_tree, true>&; boost::intrusive::bstree_impl<ValueTraits, VoidOrKeyOfValue, VoidOrKeyComp, SizeType, ConstantTimeSize, AlgoType, HeaderHolder>::insert_commit_data = boost::intrusive::insert_commit_data_t<boost::interprocess::offset_ptr<boost::intrusive::compact_rbtree_node<boost::interprocess::offset_ptr<void> >, long int, long unsigned int, 0> >]: Assertion `( p == this->end() || !this->comp()(*p, value) )' failed. "Need input on this or is this expected behaviour as per boost??" -- Regards, Murali Kishore

4 7

Shorter syntax for using a class constructor as a transform function.
by Andrzej Krzemienski 30 Sep '24

30 Sep '24

Hi Everyone, I would like to check if something like the following would be a useful addition to Boost.Core, or if something like this maybe exists: I have a class like ``` struct X { std::string str; explicit X(const std::string& s) : str(s) {} }; ``` I need to transform a vector of strings into a vector of X through invoking the constructor of X: ``` std::vector<std::string> strings = {"cat", "dog", "emu", "fox"}; std::vector<X> xs; std::transform(strings.begin(), strings.end(), std::back_inserter(xs),[](auto const& s) { return X(s); })); ``` It works, but a shorter version would be to introduce a component that is equivalent to the lambda: ``` std::transform(strings.begin(), strings.end(), std::back_inserter(xs), construct<X>)); ``` The full example: https://godbolt.org/z/85YoP9Pa9 Regards, &rzej;

4 4

Boost Asset Stewardship Review Result - Fiscal Committee Name
by Glen Fernandes 30 Sep '24

30 Sep '24

Ion wrote: > Fiscal Sponsorship Committee/Group sounds straightforward to me, > to make clear this group has no other duty than that. Thank you Ion - I agree. "Fiscal Sponsorship Committee" has my acceptance. Glen

3 2

Boost Asset Stewardship Review Result
by Glen Fernandes 29 Sep '24

29 Sep '24

Dear Boost developers and users, This concludes the Boost Asset Stewardship review was conducted between 09/03 and 09/22. I want to thank everyone who submitted a review and everyone who otherwise contributed to the discussion. What follows is my review result. For fairness and for the record, this is my connection to all parties involved: For the Boost C++ libraries I am or have been: - A Boost library author, - A maintainer of at least three Boost libraries, - A contributor to at least ten other Boost libraries, - A review manager of at least two Boost reviews, - A release manager, - A maintainer of the Boost GitHub organization, - A moderator of the Boost mailing lists, For the Boost Foundation I am or have been: - A former member of the Boost Steering Committee - A director on the board, For the C++ Alliance I have been: - A volunteer that helped review project specifications and resumes, On behalf of the Boost community, I accept the C++ Alliance Fiscal Sponsorship proposal with the following condition: - The new committee should be named something which clearly indicates that its purpose is confined to Boost's assets or infrastructure. There should be no confusion or question over whether it has any control or even other influence over the C++ library development. Please avoid any mention of "Steering" or "Direction". I accept the three initial members of the committee as proposed (Ion, Rene, Joaquin) without reservations. All three are Boost developers whom I respect and I am confident of their ability and their desire to serve the Boost community. While I appreciate the invitation to join, and would otherwise never refuse an opportunity to help Boost, I feel like my making the acceptance decision of the founding committee should prohibit me being on that list. The reviews and the discussion has convinced me that the Fiscal Sponsorship model is the right choice for Boost going forward. - It provides us with the financing we need now, and secures a very credible path for depending on them going forward. Moreover, it puts the administration of those resources in the hands of those representing our community. The Foundation can and has tried to achieve the same thing, but it should be obvious that it does not have the same level of financial resources, or technical and legal expertise at its disposal. - It has the support of a great majority of the Boost community. It is no secret that there has been a growing rift between the Boost developers and some of the Foundation members, despite my and others best attempts at healing it. Even with the same resources provided to the Foundation, I don't see it achieving the same level of acceptance and consensus that the C++ Alliance has. I want to thank the C++ Alliance for crafting this proposal, and giving us a solution for supporting those parts of Boost infrastructure that are increasingly expensive and complex to manage. This will allow the rest of us to focus on what we love doing: Working on C++ libraries. And I would be remiss if I did not repeat my gratitude to the C++ Alliance and to Vinnie for those times in the past he has come to Boost's rescue, many of these at my request. Next, I want to thank all present and past members of the Foundation and the Steering Committee for their service to the Boost project. Especially, I want to thank Michael Caisse for all the time and energy he has dedicated over the years to supporting the parts of Boost site and mailing lists that we take for granted. On that same note I want to thank the Foundation for agreeing to this review and committing to its result. If nothing else, I hope this act alone demonstrates to the community that despite past events, the intention of the Foundation is to act in accordance with the community's wishes. I would also like to make it known that I will submit a suggestion in the next meeting that the Boost Foundation rename itself to not include the word "Boost". Ultimately, it will come down to a vote between the board members, but I believe this is the best thing for the Foundation. Just as the rename from BoostCon to C++Now enabled the conference to achieve its goals of reaching the broader C++ community, the hope is that this will similarly enable the Foundation to succeed with its current mission, which spans beyond Boost. Finally, I want to repeat my thanks to the community for their voice in this review. While the list above of my involvement in Boost might seem significant, it really is not. I have contributed a small fraction of what some of the people who participated in this review have. But all of us are here because we are invested in Boost and want it to succeed more than it has already. And I hope that the decision above will help Boost do just that. Sincerely, Glen

8 13

Re: [boost] Boost Digest, Vol 7351, Issue 3
by Alfredo Correa 26 Sep '24

26 Sep '24

Hi Andrzej, Thanks for the continued conversation. > From: Andrzej Krzemienski <akrzemi1(a)gmail.com> > Subject: [boost] [multi] A successor to Boost.MultiArray? > Did I get it right that Multi can be considered a superior alternative to > Boost.MultiArray? > yes If so, it triggers a couple of points: > * Can Boost.MultiArray be upgraded instead? > MultiArray is a superset of BMA. I have a test in the CI to show that this library fulfills all the concepts BMA defines. There are still semantic differences in BMA, such as the quality of implementation issues or plain semantic bugs. Before we go down this road, I did try many times to overhaul BMA. The architecture of BMA is beyond repair. Some obstacles seem to be even purposeful features of the library, such as disallowing the assignment of arrays of different sizes. Layout information is heap allocated. Iterators are broken and too basic. Subblock views have a complicated, inefficient implementation. The lack of responsiveness of the original authors was also an issue. Don't get me wrong, BMA was a tour-de-force at the time. It even spearheaded C++ concept checking in C++98, which I have delayed integrating into the library until C++20 Concepts. * The same questions, "is it useful at all", apply also to Boost.MultiArray. > BMA is useful in principle and was a great leap forward then. In practice, it is unfortunately almost unusable. You can tour Stackoverflow questions on #boost-multi-array and see all its pain points. > * Whatever the motivation for using Boost.MultiArray is, it should also be > a good motivation for Multi. > yes > I read in the Boost.MultiArraydocs that it is a better replacement for > vector<vector<...>>. Yes, but this is a simplistic description. It is mainly used to explain the multi-index element access A[i][j], etc., but the analogy ends there. Of course it is a completely different data structure, vector<vector<...>> is more general (at a price), the "rows" can be staggered. In any case, it is, at worst a replacement for vector<vector<vector.< ....>>> *recursively*. > So, maybe a good use case is for simple use cases, > where you want to store and perform a simple access to relatively > small-sized data sets, where performance is important, but not > super-critical, and changing from nested vectors to Multi is already good > and sufficient an optimization. > I don't know how you conclude this is for small-sized data? Do you mean that vector<vector<...>> would be ok for large-size data in contrast? I don't think so. > As a side note, when comparing Multi with std::mdspan. The latter requires > C++23, while the former, only C++17. So, when someone has C++17, mdspan is > not an option. yes > BTW, why do you require C++17? > - The main reason was for ease of development: - implementing allocator propagation without if-constexpr is a nightmare. - c++17 provides polymorphic allocators, and I wanted to be compatible with them (at the time, I didn't know about __has_include, it was much simpler to just use C++17) - If I remember correctly, I could use some constexpr algorithms and make the arrays fully constexpr. These are not hard reasons to require C++17. I can port it to C++14 as soon as any user asks for it, but it hasn't happened yet. In fact, Vinnie Falco promised a gazillion dollars from Microsoft to port it back to C++14. ;P ( https://cpplang.slack.com/archives/C27KZLB0X/p1682786897070269) Thank you, Alfredo

2 2

A More Welcoming Community
by Vinnie Falco 26 Sep '24

26 Sep '24

We could stimulate participation, help the community cohesion, and provide a convenient place to post a rules reminder link. When someone signs up for the mailing list there can be an option checkbox if they want to have their name announced to the list. For example, upon signup, mailman could send something like this: From: boost(a)lists.boost.org Subject: New Member Please welcome "Patrick Programmer" to the Boost Developer's mailing list! As a friendly reminder please familiarize yourself with tips from the Boost Discussion Policy described here: https://www.boost.org/community/policy.html What do you think? Thanks

10 21

[multi] A successor to Boost.MultiArray?
by Andrzej Krzemienski 25 Sep '24

25 Sep '24

Alfredo, Did I get it right that Multi can be considered a superior alternative to Boost.MultiArray? If so, it triggers a couple of points: * Can Boost.MultiArray be upgraded instead? * The same questions, "is it useful at all", apply also to Boost.MultiArray. * Whatever the motivation for using Boost.MultiArray is, it should also be a good motivation for Multi. I read in the Boost.MultiArraydocs that it is a better replacement for vector<vector<...>>. So, maybe a good use case is for simple use cases, where you want to store and perform a simple access to relatively small-sized data sets, where performance is important, but not super-critical, and changing from nested vectors to Multi is already good and sufficient an optimization. As a side note, when comparing Multi with std::mdspan. The latter requires C++23, while the former, only C++17. So, when someone has C++17, mdspan is not an option. BTW, why do you require C++17? Regards, &rzej;

1 0

Re: [boost] [Multi] Proposal
by Alfredo Correa 25 Sep '24

25 Sep '24

> > Date: Sat, 21 Sep 2024 20:10:25 +0300 > From: Artyom Beilis <artyom.beilis(a)gmail.com> > > I do scientific computing with large arrays, and nobody uses OpenCV. > > It would be fair if you had said that it is the de facto standard for > image processing, which I don't do. > > > > Ok... if you haven't used does not mean that it isn't very common > computing library that many developers/designers go by default. > Maybe we don't agree what numeric means, or we just work in different environments. Anyway, I would agree that OpenCV is unquestionably a standard for image processing. > > > Second, Multi is not a numerical library specifically; it is about the > logic and semantics of multidimensional arrays and containers, regardless > of the element type. > > ... > > > See, this is exactly the problem. Why would I need something like that > if I need to go to all the 3rd party libraries to actually use one > efficiently? > The same reason some of use the standard library containers, or ranges, etc, even if they don't "do everything". > cv::Mat is numpy like NDArray with strides, windows, offsets (yes it > supports more than two dimensions). I myself used/written several > Tensor like objects and used (pytorch C++ tensor, dlprimitives > and other objects). It is nothing new, by all means it is the easiest > part of any numerical library. > I don't know how generically OpenCV can treat strides, windows, offsets, etc.; I trust you. Again, this boils down to compare apples with oranges, frameworks vs components. I don't have experience with OpenCV, I have seen code using with OpenCV, it seems it has a lot of features, you can load images, render windows, and do some array computations. It doesn't look like generic code to me, STL can not be used directly, for example (which is fine). I propose that, if you need to read images, and do the standard things that openCV is build for, such image processing, and probably much beyond, by all means use OpenCV. And I propose that if you need to do generic programming with standard algorithms, iterators, and some level of abstraction, use Multi, or something else. If you are not interested in the second (which is fine) then you are not the right audience for the proposed library. > >> > >> 2. While actual ndarry handling is nice, it is basically a tip of an > >> iceberg. You need a decent set of high performance algo combined with > it. > > > I couldn't agree more. The thing that I appreciate about generic programming and programming with components is that it separates data structures and algorithms. And if one does it right, the goal is no loss of efficiency. Of course this requires a lot of work, specially for library developers. > > > > There is a clear separation of concerns here. > > The Multi library deals with the data structure, it uses when it needs > to fulfill its semantics, the best *existing* algorithms it can in > awareness of the datastructure. > > The Multi library doesn't provide algorithms, it uses the algorithms > that are provided to it via different mechanisms. > > > > But if you don't provide algorithms, maybe I'd better take a > library/framework that does. > Exactly, that is the appeal of frameworks. Frameworks are great if they do all that you need and no less. The moment you need to do something that the framework has not contemplated you are totally on your own, without much help. There are plenty of numpy-like arrays around. Usually they are called > tensors... > I agree, and almost all of them are frameworks. I don't think anything works with existing STL algorithms, iterators. If you are not interested in this, this is not for you. > >> > > I agree, promising all linear algebra is infinite work, like > reimplenting MATLAB or Mathematica, but BLAS has a finite number of > functions. > > The philosophy of the BLAS-adaptor in particular (again, an optional > component) is to interface to what BLAS offers and not more. > > It is more of a model how to interface a legacy library using the > features of Multi. > > > But that is exactly what make opencv useful and multi-array like a > fasade with emptiness behind. > This is like saying all the STL containers are just "emptiness behind". In some sense it is true; you need algorithms, that exists separately. I understand your feelings. The emptiness that you feel, the "rest" is the algorithms and adaptors that exists separately from the data structure. There are excellent libraries for that, starting from STL. >> I did breef look into implementation and it seems to be lacking of > >> vectorization (use of intrinsics/vector operators) or have I missed? > > > > > > You missed that this is a generic, not specifically numerical, library. > > > But, you making numpy-like library... You keep bringing up numpy. Some users of the library see the analogy with numpy because of the easy of use, and I appreciate that but I don't mention numerics or numpy in the documentation, except in one or two places with very clear context. If, for you, numpy implies numerics, then you are using the wrong analogy and point of comparison. > otherwise you wouldn't be > interfacing cblas. > Would you feel better about it if I remove the BLAS adaptor? This is a completely optional component. This is to make the library more immediately useful without converting it into a framework. The interface with BLAS is very strictly to be have to use BLAS through the Multi facilities in a functional (immutable) context that is friendly, for example, to STL algorithms that take lambdas. See, if you have been talking about multi-array as advanced > std::vector of generic objects... Ok - but you don't > "Advanced std::vector of generic objects" is a fair scope for the library, thank you. I would say it is *very* advanced version of std::vector, but this is just an opinion I have. I don't understand exactly what is your complain, what do you mean with "but you don't". This is what I say in the introduction: "This library offers array containers and subarrays in arbitrary dimensions with well-behaved value semantics, featuring logical access recursively across dimensions and to elements through indices and iterators." I don't know where you read numerics in there. you direct it to the numeric computations. > I don't direct it to the numerical computation; I clearly say in the introduction that this is not a numerical library. I use build-in types (preferably ints) in the examples for conciseness. I just say that if you want to use it in numerical context, it still should be ok for that. The reason I don't and I won't explicitly rule out numeric applications in the documentation is because in my opinion there are no obstacles to put to use the library in numerical context. The library is in fact used in numerical context by other projects. > The other thing to take into account is that > vectorization/parallelization is still provided by the external algorithms > the library uses internally. > > For example, then dealing with GPU or OpenMP arrays, the library uses > thrust algorithms if they are available, which are parallel. > > > Just for the record there are two levels of parallelization on CPU > level: 1 thread based parallelization, 2nd SIMD level parallelization > like SSE/AVX2/Neon - where you load vectors of 16, 32 bytes of data > and process them together in a single instruction. > These can increase the performance significantly. Yes, I gave the example about thread paralellization, through execution policies, because it is cleaner. SIMD parallelization is more difficult to apply in general because it depends on data to be continuous in at least one dimension, which is only realized by very specific layouts (this is the reason BLAS matrices always have at least one stride = 1). This is not the general case, when you manipulate arrays dynamically. But I agree it still can be applied with some effort. I would do everything I can to offer the possibility of doing SIMD through the library in combination with external algorithms and lift any obstacles to it, if there are any. Having said that, it is not a big concern for the library implementation because 1) it is not numeric specifically, 2) semantic operations in the library, such as assignment or construction do not involve computation. However, if you have a clear idea how to enable SIMD for a particular problem you are free to do it, once again, through specialized algorithms. > > OpenCV isn't 2d only. It support n-D tensors with views. > Ok, I stand corrected then. @Artyom, Can you help me understand how it compare in these aspects that are important for my library? I bet OpenCV will do very well in the comparison. It is a simple checkbox list. - external Deps ? - Arbritary number of dims (e.g. 11 dimensions) - Non-owning view of data (e.g. manipulate view memory provided by others) - Compile-time dim size - Array values (owning data) (e.g. can I put arrays inside a std::list?) - Value semantic (Regular) (can I assign, swap, with expected Stepanov regularity results) - Move semantics (e.g. will this copy data arr2 = std::move(arr1) ?) - const-propagation semantics (e.g. Mat const arr; ... is arr really read-only) - Element initialization (e.g. can the arrays be initialized at declaration e.g. Mat const arr = {1.0, 2.0, ...}) - References w/no-rebinding (e.g. can I name a subblock of an array, e.g. `auto sub = subblock of arr`? does it have reference semantics (no copy)?) - Element access (e.g. how easy is to access a speicif elements, e.g. in 4 dimensions `arr( 3, 4, 5, 6)`) - Partial element access, (e.g. take n-th column or n-th row of a 2D array) - Subarray views (e.g. generate a "view" 2D subblock of a 2D array) - Subarray with lower dim (e.g. generate a "view" nD subblock of a mD array, where n < m). - Subarray w/well def layout (e.g. access the layout of a subblock, if sunblocks can be referred to?) - Recursive subarray (e.g. can sunblocks "views" of subblocks "view" be temporaries) - Custom Alloctors (e.g. thrust::device_allocator, boost::interprocess::allocator) - PMR Alloctors (e.g. use std::pmr::monotonic_memory_resource) - Fancy pointers / references (e.g. use memory not represented by raw pointers, e.g. thrust::device_pointer, boost::interprocess::offset_ptr) - Stride-based Layout (e.g. supports strides layout, element, and can gives this information to low level libraries) - Fortran-ordering (e.g. left-index is the fast index in memory) - Zig-zag / Tiles / Hilbert ordering / (e.g. fancy layouts beyond strides) - Arbitrary layout (e.g. can data be laid out arbitrarily in memory in a user-defined way, not strides, not zig-zag) - Flattening of elements (e.g. any facilities to look at the elements in a flatted way beyond simply giving a pointer to the first element, which will not work for subblocks) - Iterators (e.g. have the array, in any useful sense, .begin and .end?) - Multidimensional iterators (cursors) (e.g. auto h = arr_subarray.home(); h gives access to elements but is light as a pointer) - STL algorithms or Ranges (e.g. would it work with `std::sort`, `std::copy`, `std::reduce`, `std::rotate`, or with any ranges algorithm) - Compatibility with Boost (e.g. put arrays in Boost containers, use Boost Serialization, Boost interprocess, Boost algorithms) - Compatibility with Thrust or GPUs (e.g. can the array elements be in the gpu, and use the array through its interface without segfaulting, or use thrust::device_pointer memory) - Used in production (e.g. major users or industries) > > > > I consider that Eigen, OpenCV, Kokkos, PETSc are frameworks. > > > It reminds me of a comparison of Boost.Beast and a full scale > framework like CppCMS. > When I reviewed beast it was clear that it does not do 10% of what is > expected from something > to make an actually useful web application. > I am not an expert on Boost.Beast, but it looks like you are not the typical audience for some of Boost libraries. The key to me, although not exclusively, is the availability of generic components and generic programming. > While it is nice to have an abstraction - if so either keep it basic > or go full way - you are stuck somewhere > in between std::vector ++ and something like OpenCV. > This is a fair assessment, if you see resemblances with OpenCV is welcomed but accidental, since it is a library that I don't use. Sorry if you are disappointed this library doesn't do (directly at least) things that OpenCV does; the library definitely can do other things that OpenCV can't (and you are not interested in), and even if OpenCV can do them, it will do them with an interface that I is not within the scope of the goals of my library. > > > > I don't fill confident adding an OpenCV column because I don't have > experience with it, but feel free to help me adding a library and answering > the points of each row in the comparison table. > > > I suggest getting some experience with OpenCV. It is a very good > library that already implements what you have (also in a different > way) > I doubt OpenCV implements everything that Multi has. But even if it does, it does it with a different interface that was a priority for my design. (To be fair, Multi doesn't implement everything that OpenCV does either, for sure) > It ain't perfect by any means. But it works, well debugged, understood > and is a widely available library that does the job. > I don't doubt this. I think it is good that both libraries are different, I don't need all the bells and whistles that OpenCV has and it is undeniably a heavy dependency. I don't need rendering images, loading images, or be optimized for element types that OpenCV offers. > >> What is not clear to me is why should I use one over some existing > solution > >> like OpenCV? > > > > > > - Because sometimes your elements are not numerical types. > > > Yeahhh... don't buy it. Sorry :-) > yeah, but I do need a 100x100 array of std::strings. and a 20x10 array of std::tuples. I would love to know if OpenCV can store those. > > > > > - Because sometimes you want to specify your element types as template > parameters not as OpenCV encoded types. > > > To make your code compilation slower and more horrible? Actually > OpenCV supports templated accessors. > This is the perennial discussion between header-only and pre-compiled libraries. I don't have anything to add, the idea is that you pay at compilation for what you use. Feel free to try the library in Godbolt to see the compilation times and the machine code it produces. It is a pity that OpenCV is not in Godbolt to compare both online. Having said that, I would welcome any comparison in timing and usability between the two libraries within or around the scope of what I am proposing. > > > > - Because sometimes you want arbitrary dimensionality (e.g. 2D, 3D, 6D) > to be compile-time. > > > And why it isn't possible with OpenCV > I don't know, is it possible? >From the examples I see online, all OpenCV arrays regardless of dimensionality have all the same type. Maybe I am mistaken. > > > > - Because sometimes you want to apply generic algorithms to your arrays > (STL, std::sort, std::rotate, std::ranges, boost::algorithms, serialization) > > > Yeah... good luck with that in numerical context. But Ok. I use the library in numerical context, I have no problem with that: https://gitlab.com/npneq/inq https://github.com/QMCPACK/qmcpack > In OpenCV > you can just get several pointers and work with them > You can not have it both ways. If you need a pointer and the sizes (and strides), Multi gives you access for that too; and then according to your definition, it would be equally powerful as OpenCV. https://gitlab.com/correaa/boost-multi#legacy-libraries-c-apis > > > > - Because sometimes you want to implement function that are oblivious to > the actual dimension or your array (e.g. simultaneously view a 3D array of > elements as a 2D array of something, for abstraction). > > - Because sometimes you want to control allocations, use fancy pointers, > parameterized memory strategies, polymorphic allocators, > > > OpenCV support custom allocations (actually something I exactly use > right now to monitor memory consumption) > That is great, can you point me to an example? >From what I quickly see online, openCV gives its own allocators. I am not interested in non-standard allocators for this library. It is not clear to me if you can use standard allocators and PMR allocator in OpenCV. Can it take allocators that do not return raw pointer types such as GPU? and if not, what if you allocate a raw pointer with cudaMalloc, how much of the library can you still use? > Once again - be careful what you wish for. Templated allocators are > huge headache to work with in comparison to run-time ones (in real - > non fancy template world that Boost Loves) > It is not a matter of what I wish. The library is not a framework, allocation is something that the user of the library brings in. I don't choose it for them. > > > - Because sometimes you want precise value semantics > > > I'm not sure it is a great idea for huge arrays/matrices. Virtually > ALL tensor libraries have reference semantics for a very good reason. > Sometimes you need it, sometimes you don't. If you don't need, don't make copies, don't pass by value, that is the right thing to do and allowing the option it is a priority of the library. I prevent the library to make copies as much as I can, until the user really means it. > > > > - Because sometimes you want to work with subblocks of an array in the > same way to need you work with the whole array. > > > And this is exactly what view is for... And this is common for any > tensor library. > Great, I would feel bad if I didn't provide this fundamental feature. The next question is whether arrays and subarrays/subblocks/views can be treated in equal footing. > > - Because sometimes you want to give guarantees in the presence of > exceptions (the library doesn't throw exceptions, to be clear). > > Ok this is one of the points I want to discuss here in terms of > design, exceptions and broadcasting. > Lets take an example (numpy - but same works for torch::Tensor) > > a=np.ones(5,10) > b=np.ones(2,5,1) > c=a+b > > It would perform broadcasting to Shape = (2,5,10) - automatically. How > it can be done - you broadcast shapes > of a to 2,5,10 using strides (0,10,1) and broadast b to same shape > using strides (5,1,0) (I hope I have not mistaken in calcs) > Then you can run easily on shape 2,5,10 and do all calculations, fetching > etc. > > Looking into your broadcasting docs - left me with the impression it > does not support anything like this. > What do you mean by "anything like this"? The library doesn't make algebraic assumptions about the arrays of the elements. There is no binary addition + in the library, you can define your own if you want, using well know algorithms or specializations of them. Once you tell me what is your specification and implementation of '+' I can tell you how to use broadcast for your case. If it is a good example I could even add it to the documentation. Note that + implies an algebra, I don't consider it part of the scope of the library. Broadcast instead is part of the library because I consider it a non-algebraic but very powerful array manipulation feature. Broadcast is implemented in the library within a certain design. I think you are disapointed because the broadcast is not "automatic", which is a different issue. > I read this: > > > First, broadcasted arrays are infinite in the broadcasted > dimension; iteration will never reach the end position, and calling > `.size()` is undefined behavior. > > Why? You certainly can iterate over broadcasted dimension... > Yes, you can iterate, that is fine. multi::array<int, 1> A1D = {1, 2, 3}; auto const& A2D = A1D.broadcast(); // A2D = { {1, 2, 3}, {1,2, 3}, {1,2, 3}, ....} assert( A1D[0] == {1, 2, 3} ); assert( A1D[1] == {1, 2, 3} ); ... what is your question? is your question what should A2D.size() return? > Also how do you handle incompatible broadcasting without exception - > for example if b in the example above was of shape (2,5,3) and not > (2,5,1) > The "raw" broadcast operation in the library is an operation that cannot fail. It is how the user of the broadcasted object uses it what can create problems down the road if he doesn't know what he/she is doing. The user may choose algorithms that throw when sizes are incompatible, or just assert or just continue. Who am I to choose for them? (I do it in a certain way in the BLAS adaptor but that is a completely different story). > Exceptions are useful. And claiming that you don't throw ones means > you don't use new... > Exceptions are great, that doesn't mean that every library should be throwing exceptions. And you are completely correct: the library doesn't use `new`. (I couldn't, even if I wanted since the arrays should work in especial memory too). The user of the library provides the allocator, the library itself doesn't throw. At most, it is the allocation (or element assignment) what can throw and I don't have control over that because it is an arbitrary element type and the library will handle it well. > I highly doubt the practicality of the library in the current form. > While generic multi-array can be nice to have, but actually it is > stuck at being little bit more that MultiArray > but too far even from basic numpy. > Thank you for your assessment. I think you don't agree with the scope of the library, which would be fine. May be you also think that the scope of the library is more than what I state, which is something I would like to clarify in some way. l don't think this is a little more than MultiArray, but it depends on the usage and how much you care about certain things. (there is a column in the table that will help you evaluate the differences). Thank you, Alfredo

3 3

Re: [boost] [Multi] Proposal
by Alfredo Correa 25 Sep '24

25 Sep '24

Date: Sun, 22 Sep 2024 17:13:07 +0200 > From: Seth <bugs(a)sehe.nl> > Thanks Sehe for the feedback. I answered Artyom in a separate message in the mailing list. > > On Sat, Sep 21, 2024, at 7:10 PM, Artyom Beilis via Boost wrote: > > > > But if you don't provide algorithms, maybe I'd better take a > > library/framework that does. > Perhaps. > This is the eternal discussion of frameworks vs generic components. > > But, you making numpy-like library... otherwise you wouldn't be > > interfacing cblas. > > A clear case of diyd/diyd ("Damned If You Do, Damned If You Don't"). Of > all the features you're missing here you decry "At least show ways to > interoperate with existing thirdparty libraries". Now, they went and did > that (if I'm not mistaken, clearly marked as an extension that might not > even be part of the proposed library), and you decry that. There's no > winning. > I couldn't have said it better myself. > > It [OpenCV] ain't perfect by any means. But it works, well debugged, > understood > > and is a widely available library that does the job. > > It's also a pretty heavy dependency, especially if you didn't need all the > other stuff, and appears to be an example of an intrusive framework (for > good reason, IFF you need the rest) > Right, comparing a framework with a generic component is a waste of time. One has to look at how things inside and "outside" the framework compare, and how the code scales after that. This takes a lot of time and effort and will keep boiling down to frameworks vs generic component. I will say "you can sort with std::sort a 2D array" and the other person will answer either that a) "he/she doesn't need to do that" or b) that "he/she can ask the developer of the framework to implement .sort_by_row and .sort_by_col`" or c) that "he/she can take the pointer to the data structure and do it himself". It is a never ending argument. > > Exceptions are useful. And claiming that you don't throw ones means > > you don't use new... > > Many things don't require allocation. Meanwhile `new(std::nothrow)` has > existed since c++11. > It is more general than that, the library tries to gives some guarantees for exceptions that happen during allocation or element copy/assignments. The library itself doesn't throw exceptions during these operations, but it handles the ones that the elements operations or allocators produce, if it needs to, Thank you all for you feedback, Alfredo

2 1

Re: [boost] Boost Digest, Vol 7345, Issue 1
by Alfredo Correa 25 Sep '24

25 Sep '24

Hi Artyom, Thank you for you for noticing the proposal and the feedback. > It can be excellent to have something like standard MD arrays like numpy is > today for python, but... > yes, this is one of the goals. > 1. You haven't mentioned even once OpenCV which today is the de-facto > standard for numerical computing in today's C++ world. I do scientific computing with large arrays, and nobody uses OpenCV. It would be fair if you had said that it is the de facto standard for image processing, which I don't do. Second, Multi is not a numerical library specifically; it is about the logic and semantics of multidimensional arrays and containers, regardless of the element type. Having said that, the library should still be very performant with numerical data, and for that, I delegate that responsibility to the algorithms it uses behind the scenes, which are very customizable. Unfortunately, people read "arrays" immediately jump to "numerics" and "linear algebra". >From the introduction "The library's primary concern is with the storage and logic structure of data; it doesn't make algebraic or geometric assumptions about the arrays and their elements. (It is still a good building block for implementing mathematical algorithms, such as representing algebraic dense matrices in the 2D case.) In this sense, it is instead a building block to implement algorithms to represent mathematical operations, specifically on numeric data." > While it isn't > perfect - it actually has similar features in terms of array layout - and > what is more important it has a library of high performance algorithms to > process the data. You must talk at least about interoperability between > cv::Mat and this library > Multi is not an algorithms library, but it carefully plays with existing algorithms and facilitates as much as possible to interface with many numerical libraries. > 2. While actual ndarry handling is nice, it is basically a tip of an > iceberg. You need a decent set of high performance algo combined with it. > There is a clear separation of concerns here. The Multi library deals with the data structure, it uses when it needs to fulfill its semantics, the best *existing* algorithms it can in awareness of the datastructure. The Multi library doesn't provide algorithms, it uses the algorithms that are provided to it via different mechanisms. > > Looks like there is a basic BLAS but the typical library has way-way more > to make it useful. > This is an add-on that is separate from the main library. I cannot even guarantee that it will ship with the proposed version of the library. What do you mean by the "typical library" in "the typical library has way-way more to make it useful"? I agree, promising all linear algebra is infinite work, like reimplenting MATLAB or Mathematica, but BLAS has a finite number of functions. The philosophy of the BLAS-adaptor in particular (again, an optional component) is to interface to what BLAS offers and not more. It is more of a model how to interface a legacy library using the features of Multi. > I looked over the code and didn't find include to cblas... Did I miss > something? Also I see request to link cblas/openblas or so. > Yes, you missed that depending on cblas would tie it the application to cblas, not all BLAS implementations can be used through cblas. BLAS is uses through the ABI directly. (basically I have my own version of the cblas header as an implementation detail). Also the BLAS interface is the same for cuBLAS, which is another story. > I did breef look into implementation and it seems to be lacking of > vectorization (use of intrinsics/vector operators) or have I missed? > You missed that this is a generic, not specifically numerical, library. The other thing to take into account is that vectorization/parallelization is still provided by the external algorithms the library uses internally. For example, then dealing with GPU or OpenMP arrays, the library uses thrust algorithms if they are available, which are parallel. vectorization is use by passing execution policies, or whatever mechanism the underlying algorithms use as long as they conform to a certain syntax. (there are some commits coming regarding the passing of execution policies Remember that I don't use many algorithms internally, only those that are necessary to implement the semantics of the array types, assignment, move assignment, construction and destruction. The rest of the operations generate views mostly, so they don't involve computation or algorithms. For the rest, as a user, you have to use algorithms, and I can help if you find that algorithms do not perform as you expect. > 3. Finally I do want to see comparison with stuff like OpenCV, Eigen and > even uBlas (I know it isn't good) > Multi is for multidimensional arrays, not specifically 2D numerical arrays (i.e. matrices). I would be interested in improving the code if someone claims that operations in these libraries are better performant. I wouldn't want the documentation to be a comparison with so many libraries to which there is just very partial overlap. Specially I don't like to compare with frameworks that lock you in into using their own facilities. I consider that Eigen, OpenCV, Kokkos, PETSc are frameworks. Eigen is listed in one column comparing to other libraries. https://gitlab.com/correaa/boost-multi#appendix-comparison-to-other-array-l… I don't fill confident adding an OpenCV column because I don't have experience with it, but feel free to help me adding a library and answering the points of each row in the comparison table. 4. If you do implement many high performance algorithms this library by any > means shouldn't be header only. > I don't implement any high performance algorithms here, I just give the possibility to interface with them and use them internally when needed to fulfill the semantics of a container. > What is not clear to me is why should I use one over some existing solution > like OpenCV? > - Because sometimes your elements are not numerical types. - Because sometimes you want to specify your element types as template parameters not as OpenCV encoded types. - Because sometimes you want arbitrary dimensionality (e.g. 2D, 3D, 6D) to be compile-time. - Because sometimes you want to apply generic algorithms to your arrays (STL, std::sort, std::rotate, std::ranges, boost::algorithms, serialization) - Because sometimes you want to implement function that are oblivious to the actual dimension or your array (e.g. simultaneously view a 3D array of elements as a 2D array of something, for abstraction). - Because sometimes you want to control allocations, use fancy pointers, parameterized memory strategies, polymorphic allocators, - Because sometimes you want precise value semantics - Because sometimes you want to give guarantees in the presence of exceptions (the library doesn't throw exceptions, to be clear). - Because sometimes you want to work with subblocks of an array in the same way to need you work with the whole array. Thanks, Alfredo

4 7

Re: [boost] [Multi] Proposal
by Alfredo Correa 25 Sep '24

25 Sep '24

> > > > Date: Sun, 22 Sep 2024 17:30:04 +0100 > From: John Maddock <jz.maddock(a)googlemail.com> > To: Seth via Boost <boost(a)lists.boost.org> > > >> But, you making numpy-like library... otherwise you wouldn't be > >> interfacing cblas. > > A clear case of diyd/diyd ("Damned If You Do, Damned If You Don't"). Of > all the features you're missing here you decry "At least show ways to > interoperate with existing thirdparty libraries". Now, they went and did > that (if I'm not mistaken, clearly marked as an extension that might not > even be part of the proposed library), and you decry that. There's no > winning. > > +1, I've only been lurking in this conversation, but it seems to me that > trying to compete with low level and highly optimized BLAS libraries is > a fools errand. > I completely agree, I am not even going to try to include vectorized operations inside this library, even as a specialized cases But I will do anything I can for people to be able to exploit them when possible through algorithms and execution policies. At most what I am doing is to interface with BLAS the best I can with some features that are unique to the library in what personally I think is a fairly original way. (capturing a functional-programming interface). Other *numerical* libraries went that way and that is commendable. Thank all for the feedback, Alfredo

1 0

Asset Stewardship Review
by Arnaud Becheler 23 Sep '24

23 Sep '24

I support the C++ Alliance proposal to transfer assets to it and to form a new Steering Committee. I have been using Boost for almost a decade now for my science project, and had some interactions with its community. - My first interaction with the Boost mailing list was to evaluate whether my small science library might be a suitable proposal. The response was pretty clear: no. Boost was seen as too large, and my project too niche (plus, I assume there might have been some quality concerns as well). While I understood the rationale, it did discourage me from further participation in the mailing list. After all, if my project couldn’t be part of Boost, what was the point of staying engaged and spammed ? This experience might help explain at least one data point in the chart from the Alliance proposal, which highlights the mailing list’s decline in participation. - On the other hand, I was still actively using Boost and seeking a community. I was pleasantly surprised by how welcoming the community was to beginners, especially on the Cpplang Slack channel. As a gay person who enjoys sprinkling my Slack posts with rainbow kitties, I never felt ostracized or discriminated against, nor did I witness any bullying. It seems like the community self-regulates quite well, without an apparent need for the enforcement mechanisms proposed by the Foundation. - More significantly, I only became aware of the Foundation through these proposals. I've never had the chance to interact with any of its members, except for Peter, which makes me a bit skeptical of their motivations. In contrast, members of the C++ Alliance—like Vinnie, Rene, and Joaquin—have been consistently accessible and supportive on the Boost channel of the Cpplang Slack. - The quality of the proposal documents is worth noting: the C++ Alliance’s proposal is highly detailed, well-illustrated, and presents a long-term vision that reignited my enthusiasm for the community. In contrast, the Foundation’s proposal felt more like a brief but reassuring affirmation of the importance of our long-held open-source values, without sparking the same level of excitement. Additionally, members of the C++ Alliance were readily available for real-time discussions and debates about their proposal, whereas members of the Foundation were less/not present and communicative on the platforms I personally use. - I believe in values, principles—and results. I can highlight the success of the C++ Alliance with two personal stories. (i) Recently, a colleague mentioned that Boost was outdated and irrelevant. I disagreed and showed them the new website developed by the C++ Alliance. They quickly changed their mind. (ii) Similarly, a colleague who had switched to Rust was convinced C++ was obsolete due to well-known C++ vs. Rust issues. They even compiled a bullet-point list to persuade others to move away from C++. I showed them the C++ Alliance’s Safe C++ initiative in partnership with Sean Baxter. After reading it, they came back excited, saying the proposal addressed every point on their list and could be a game-changer. Unfortunately, I don’t have comparable stories about the Foundation. - As several reviewers have pointed out, there are shared goals and ideologies at the core of the conflict. The community must embrace these common values and reinforce the collaborative spirit that Boost was built on, ensuring the focus remains on innovation and mutual progress rather than division. Continuing down this path of personal conflict only detracts from the mission, diluting the collective potential of the project. It’s essential that we return to a focus on the project's true objectives—technical excellence, inclusivity, and shared success. By prioritizing cooperation and mutual respect, we can ensure that Boost remains a thriving environment for growth. I personally take home these points from the two proposals: - *Foundation Proposal:* - Uphold core values of the open-source community (openness, collaboration, inclusivity). - Push for immediate inclusivity. - Concerned that financial involvement may compromise the project’s integrity. - Recognizes the importance of not becoming too distanced from the community. - Move slowly, but surely, and freely. - *C++ Alliance Proposal:* - Leverage funding to handle unappealing yet necessary tasks. - Focus on modernizing and appealing to younger developers. - Aim to keep the project relevant and attractive to new talent. - Want to maintain a close relationship with developers. - Move fast and throw money at problems. - *Conclusion:* - Both the C++ Alliance and the Foundation share aligned values but focus on different approaches. - They are complementary, addressing different aspects of the same mission. - Their coexistence can provide a balance, acting as counterweights to maintain both ethical standards and practical sustainability. - Transferring assets to the C++ Alliance would enable them to fulfill their part of the mission more quickly. I don't believe it would impede the Foundation's ability to achieve their goals. - The next question for the community is: how can we support the Foundation in return? For example, a reasonably-sized data science project to collect insights on inclusivity and diversity within the Boost community could help them shape future initiatives around the values they prioritize, and would benefit the entire community. Thank you once again for giving us the chance to review these great documents and visions, and for the hard work from all sides that has allowed me to develop my little science project while standing on the towering shoulders of giants ;) Best, Arno

4 3

CODE_OF_CONDUCT.adoc
by Vinnie Falco 23 Sep '24

23 Sep '24

The subject of a code of conduct has come up a few times, and I think it is worth having a discussion. I hope that everyone will find the following statements uncontroversial: 1. Social spaces have rules, either stated or implied 2. Rules need to state clearly what is allowed and what is disallowed, so that people who may be interested in joining can determine if the culture is the right fit. 3. Rules need to be enforced 4. The Boost mailing lists already have rules 5. The rules for the mailing list are outdated 6. The rules for the mailing list are not particularly visible There is value in refreshing the rules for the Boost mailing list, which are currently described here: https://www.boost.org/community/policy.html I think we should do the following: * Update the rules to be relevant for 2024 * Make the rules visible on the sign-up and administration page for the mailing lists (at https://lists.boost.org) * Consider renaming the rules to something other than "Boost Discussion Policy" * Send a periodic announcement to the mailing lists reminding everyone of the rules. These could be timed to coincide with the releases (three times per year) The community needs to discuss the things above and come to a consensus. And we need to make a final decision on what the changes will look like given the feedback. I don't know that the review process is right for this, because it will likely be an iterative process where we all work on a "shared document" to make edits. The nice thing is that we don't need to wait for the outcome of the Boost Asset Stewardship review to do this, because the content of the website and mailing lists is not controlled by the Boost Foundation, the C++ Alliance, or the proposed Steering Committee. And even before the need to decide which revision of the updated rules will be accepted by the project, discussion can take place with no governing body. There is one hiccup though. Where do we discuss this? The mailing list is one possibility. However, anyone who joins the mailing list late, or is not a member of the mailing list, has the problem that the visibility of the discussion is not very great. They would have to use the archives, and the archives are not very pleasant. One cannot see the entire discussion as a single page. And if someone changes the subject, then new related threads of conversation become more difficult to find. And at the end of the day, our workflow requires GitHub issues to triage and assign work items to staff. Therefore, here is a GitHub issue for this. Everyone can feel free to participate in a discussion there. Alternatively, if you feel that the mailing list is a better place, then reply to this post and have a discussion here. There might be two discussions. Or one. Or none (hopefully not). And when we are done we can compare the pros and cons of GItHub issues versus the mailing list. There could be value here. This is the issue: https://github.com/boostorg/website-v2/issues/1269 What do you think? Thanks

3 4

Asset Stewardship Review
by Adam C Getchell 23 Sep '24

23 Sep '24

I support the C++ Alliance proposal to transfer assets and form a new Steering Committee. I’ve been a downstream user of Boost for more than a decade for my research project, and joined the mailing list to get help on using the project effectively. My initial interactions were to sort out build errors, which were mostly resolved with the adoption of vcpkg (after trying biicode and then Conan) and the work on making Boost compatible with CMake. I have appreciated the C++ Alliance’s sponsorship of tools such as the Slack workspace and CI, and I believe this is necessary to ensure progress. I also learned a lot reading the documentation and code of Louis Dionne’s Boost.Hana and Vinnie Falco’s Boost.Beast. As a side note, my research involves writing low-level simulations of the universe, and unfortunately the various memory errors and other bugs have convinced me to go reluctantly down the path of using Rust to write low-level memory-safe abstractions that I can count on to run for months at a time without segfaults or other issues that compromise the validity of the data. Thus, Circle and the recent Safe C++ proposal are very interesting to me, and if they are ever adopted I might back port them to my current codebase. However, this probably won’t be effective until the libraries I depend on make similar efforts. By then, I will probably have everything I need written in Rust. -- Adam Getchell https://adamgetchell.org <https://adamgetchell.org/>

1 0

Boost.LEAF in Embedded Systems (CppCon)
by Vinnie Falco 23 Sep '24

23 Sep '24

At CppCon 2024 the C++ Alliance sponsored a program to interview conference goers about Boost-related topics. This is the first video in the series: Boost.LEAF in Embedded Systems: Insights from Ex-Google Engineer Khalil Estelle at CppCon https://www.youtube.com/shorts/BksBxnTLltY Enjoy! Thanks

1 0

Boost Asset Stewardship Review begins today (3rd Sept)
by Glen Fernandes 22 Sep '24

22 Sep '24

Dear Boost community, The Boost Asset Stewardship Review begins today, 3rd September and ends on 22nd September. For reference, the review schedule is: https://www.boost.org/community/review_schedule.html The submission which initiated the review is the following proposal from the C++ Alliance: https://cppalliance.org/pdf/Fiscal-Sponsorship-Proposal.pdf It proposes a Fiscal Sponsorship which: 1) is a legal agreement where the C++ Alliance holds assets on behalf of the Boost project. It proposes a newly formed (steering) committee that would be composed of Boost developer community members that would determine how the assets are used. 2) donates the assets that it funds to the Boost project (domains, hosting, etc.) The "Boost developer community" here refers to: - Boost library authors - Boost library contributors - Boost release managers For a high level overview of these terms (which I needed) see the following email with definitions: https://lists.boost.org/Archives/boost/2024/09/257579.php The Boost Foundation asks the Boost developer community to consider the following alternative: https://docs.google.com/document/d/1XFt7Bh71e4_uE0iK4jifhR__P0iG5_c1cDfBsMj… The Boost Foundation proposal presents a path forward where it continues to be the steward the assets in question, but offers a change in how these are managed. The assets here refer to the following: - The boost.org domain - Website hosting - Mailing lists - Downloads storage and CDN - Drone CI Currently, the Boost Foundation owns and pays for the following: - Website hosting - Mailing lists The C++ Alliance pays and manages for the following: - The Drone CI - The CDN for the downloads - The download archive - Technical assistance and support for the Boost release process - Backup domain names (in case boost.org expires) - Hosting and downloads for the new website prototype (boost.io) The boost.org domain is absent from both lists above: The Boost Foundation technically does not own it yet. The domain was owned by Beman and he had the credentials. The Boost Foundation is working with Beman's widow and the Dawes Estate to transfer ownership to it. For reference, see Kristen's email: https://lists.boost.org/Archives/boost/2024/08/257563.php Note that the content of the current boost.org site and the new boost.io website is still the province of the Boost developer community. To be clear, the review is not about deciding governance over Boost C++ library development. That remains in the hands of the Boost developer community. Please send all reviews to the Boost developer mailing list. If you do not want to create an account, you can email me at glenfe -at- boost.org with your review and I will post it to the list for you. Include "Asset Stewardship Review" or "Asset Stewardship" in your email subject. In your review do disclose any affiliation to either the C++ Alliance or Boost Foundation groups. Please state any connection you have to Boost (developer, user, package manager etc.) Thank you, Glen

15 26

Boost Asset Stewardship Review concludes 09/22
by Glen Fernandes 21 Sep '24

21 Sep '24

Everyone, Tomorrow (September 22) is the last day to submit a review. To date there have been no requests for an extension. I have received suggestions for potential reviewers I should reach out to, and I believe only one review is forthcoming. Thank you to everyone who has submitted a review, or has otherwise contributed to the discussion. Glen (I was reminded that there are still answers pending from certain members of the Boost Foundation. I understand that CppCon is ongoing and they might not be able to reply yet).

1 0

Re: [boost] Boost Digest, Vol 7346, Issue 1
by Alfredo Correa 20 Sep '24

20 Sep '24

Hi Seth, On Fri, Sep 20, 2024 at 5:00 AM <boost-request(a)lists.boost.org> wrote: > > Date: Thu, 19 Sep 2024 16:28:28 +0200 > From: Seth <bugs(a)sehe.nl> > > On Thu, Sep 19, 2024, at 1:13 PM, Artyom Beilis via Boost wrote: > > 1. You haven't mentioned even once OpenCV > > [...] > > 4. If you do implement many high performance algorithms this library by > any > > means shouldn't be header only. > > > > What is not clear to me is why should I use one over some existing > solution > > like OpenCV? > > All of the points raised are actually a single one, and seem to > misunderstand the scope of the library? I suppose it should be seen as a > successor to Boost MultiArray, leveraging modern language features and > side-stepping some of the pitfalls. > yes, exactly. You seem to understand exactly what I am talking about. (Also a big fan of your Stackoverflow answers). I just gave a long answer to Artyom's message in the list. > That's not at all useless, and interop examples would be very valuable. > However, not all code needs vectorization (beyond what the compiler will > automatically do). I'm more interested in the relation to > https://en.cppreference.com/w/cpp/container/mdspan - which seems to fill > the same space: building block for flexibly indexed contiguous storage. > >From this section: https://gitlab.com/correaa/boost-multi#substitutability-with-standard-vecto… "Multi-dimensinal arrays can interoperate with C++23's non-owning mdspan. Preliminarily, Multi's subarrays (arrays) can be converted (viewed as) mdspan." https://godbolt.org/z/aWW3vzfPj Also see https://gitlab.com/correaa/boost-multi#appendix-comparison-to-other-array-l… Thank you, Alfredo

1 0

Video on Boost.Cobalt available
by Richard 20 Sep '24

20 Sep '24

Utah C++ Programmers has released a video on the Boost.Cobalt coroutines library: Using Coroutines with Boost.Cobalt <https://www.youtube.com/watch?v=yElSdUqEvME> -- "The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline> The Terminals Wiki <http://terminals-wiki.org> The Computer Graphics Museum <http://ComputerGraphicsMuseum.org> Legalize Adulthood! (my blog) <http://LegalizeAdulthood.wordpress.com>

2 1

Asset Stewardship Review
by Phil Endecott 19 Sep '24

19 Sep '24

I've been a Boost user and subscriber to this mailing list for most of this century, but I'm not a library author. It's tempting to write a long navel-gazing essay about the history of Boost and what it needs to do to remain vital, and then to pretend to forensically study the competing proposals to determine which will give the best result in the longer term. But in this post I'll try to be more honest: isn't this review more like a referendum on whose side we favour in the Vinnie Falco vs. David Sankel clash of personalities? Somehow we've reached a point where "this town ain't big enough for the two of them" and we're being asked to choose who to exile. What do I think about the Boost Foundation? I have always been mystified by why the Foundation, and the Steering Committee before them, have interacted so little with the list. The most extraordinary example of this was that the very establishment of the Foundation was not announced to the developers! Periodic, brief updates on Foundation activities to the mailing list would not have taken much effort could even have resulted in more offers of help. The foundation's present proposal starts by talking about "Transparency"; perhaps they would be more transparent in the future, but that would be a departure from how they have worked in the past. Regarding Vinnie and his C++ Alliance, I've not had a very positive view of them since he posted this back in 2023: "Something which should not surprise anyone is that I despise paying taxes." This statement is repeated in his current proposal. Personally, I'm proud of the tax that my business and I pay as it funds education, health, pensions and other public services that make my community a better place in which to live. In the world I inhabit, this is a mainstream view. It's one thing to despise paying taxes, but I think it's quite another to tell everyone that and assume that they share the same view. When I read that the boost.io domain for the "temporary" website had cost $135,000, my reaction was that you could feed a lot of hungry children with that sort of money. My conclusion is, "a plague on both your houses". I fear that Boost is doomed. This review will result in Vinnie's hostile takeover succeeding, but eventually he'll lose interest - maybe when the "young developers" that he hopes to attract don't materialise, or maybe after another falling-out with someone else. Then the project will sink. I think this is the right time for me to unsubscribe from this list; being here doesn't help me, and my contributions don't seem to help anyone else. I extend my best wishes and thanks to all those whose libraries I have used over the years. Regards, Phil.

6 5

Re: [boost] proposal Multi multidimensional array library
by Artyom Beilis 19 Sep '24

19 Sep '24

Hi, Only now have I noticed this proposal, and here are some of my thoughts. It can be excellent to have something like standard MD arrays like numpy is today for python, but... 1. You haven't mentioned even once OpenCV which today is the de-facto standard for numerical computing in today's C++ world. While it isn't perfect - it actually has similar features in terms of array layout - and what is more important it has a library of high performance algorithms to process the data. You must talk at least about interoperability between cv::Mat and this library 2. While actual ndarry handling is nice, it is basically a tip of an iceberg. You need a decent set of high performance algo combined with it. Looks like there is a basic BLAS but the typical library has way-way more to make it useful. I looked over the code and didn't find include to cblas... Did I miss something? Also I see request to link cblas/openblas or so. I did breef look into implementation and it seems to be lacking of vectorization (use of intrinsics/vector operators) or have I missed? 3. Finally I do want to see comparison with stuff like OpenCV, Eigen and even uBlas (I know it isn't good) 4. If you do implement many high performance algorithms this library by any means shouldn't be header only. What is not clear to me is why should I use one over some existing solution like OpenCV? Artyom On Thu, Apr 27, 2023 at 12:30 AM Alfredo Correa via Boost < boost(a)lists.boost.org> wrote: > Hi all, > > My name is Alfredo. > I would like to propose this library called Multi for inclusion in Boost. > Multi is a container and views library for (dynamic) multidimensional > arrays. > > The library is available here, > https://gitlab.com/correaa/boost-multi. > >

2 1

Boost Asset Stewardship Review begins 09/03 (Updated)
by Glen Fernandes 18 Sep '24

18 Sep '24

Update: The Boost Foundation proposal mentioned in the original announcement has been published. The Boost Foundation proposal is attached to this email: BoostFoundationStewardshipProposal.pdf A link to the above will also be available in the review commencement email that will be posted on September 3rd. For reference, the review schedule is: https://www.boost.org/community/review_schedule.html The C++ Alliance submitted the following proposal: https://cppalliance.org/pdf/Fiscal-Sponsorship-Proposal.pdf The original announcement email included an attachment of the above: https://lists.boost.org/Archives/boost/2024/08/257569.php - Glen

19 47

Boost Asset Stewardship Review from René
by René Ferdinand Rivera Morell 18 Sep '24

18 Sep '24

== Distractions: Before I get to the meat of the review I need to point out that I will not talk about: if Boost needs a new website, whether Boost needs to be revitalized, if policing communications in Boost is a good idea or not, if Boost is relevant any longer, what build system Boost should use, what documentation system Boost should use, if Boost is attractive, if some other project is the new-old Boost, if Discord is better than email. All of those, and more, are distractions to the key questions that we are deciding on: * Who should manage the assets that sustain the development of Boost Libraries? * Who should decide how those assets are managed? == Disclosure, Present Seeing as the C++ Alliance proposal lists me as one of the initial members of a new Committee I thought I'd include additional biographical background for those that may not be aware of what I've done, and do, both in the foreground and background of programming. In case some are not aware I wear many hats in my life. And some of them intersect with the Boost community. Because of the kind of work that I've traditionally done, and still do, in game development and contracting in that domain I have learned to compartmentalize facets of my life. And how to reorient my thinking to each facet as needed. Below is a very brief exposition of current and past involvement arenas. *Chicago Developer Development NFP* I currently serve as a member of the board of the Chicago Developer Development NFP. This is a non-profit that manages the finances of the Chicago C/C++ User Group. Although the non-profit is very new, the user group has been around for almost as long as Boost. And I've helped manage it for just about as long. *Disbelief LLC* My day job for Disbelief is now at about 9.5 years doing AAA game development consulting. Mainly doing Unreal Engine systems and graphics programming. The one intersection with Boost here is that we happen to use Boost in an internal project. And Boost is used in the internals of Unreal Engine (at one point it had at least 4 different copies of Boost in it at once). *C++ Alliance* I currently serve as a member of the board of the C++ Alliance and hold the position of Secretary. As mentioned in the C++ Alliance proposal my duties include advising on the non-profit operation and alignment of initiatives with the goal of advancing the C++ ecosystem. My experience in Boost and running various nonprofits and for-profit corporations is particularly useful. The C++ Alliance also makes it possible for me to participate in WG21 where much of my time has been spent in C++ tooling and the standardization of tool interop. *Boost C++ Libraries* I currently maintain Predef and B2. I am currently working to make the B2 build support in Boost allow for modular usage. With the hope of making it easier to support package managers and the desire from some users to depend on just the Boost libraries they need. In the past I created the current Boost website, which is the second iteration. I provide advice on the development of the new website. I provide advice on the packaging of Boost for Conan. I maintain the B2 Conan package which is separate from the Boost Conan package. In the past I've also served as Boost Documentation Manager during which I helped maintain Quickbook. I also served as Boost Release Manager during which I automated much of the labor using cloud CI. I also served as Boost Testing Manager during which I tried, but failed, to improve the global test matrix but at least kept it running. And long ago I minimally helped to start BoostCon. *Bincrafters* Bincrafters is a group that got started at the early stages of the Conan package manager. We created many packages for libraries of all sorts. I joined at its foundation to do one main task, to create the first modular set of Boost packages. Although that modular Boost packaged release is no longer available it taught me many lessons that I applied to the current modular B2 building. That effort also provided the conceptual model for the current modular vcpkg Boost packages. Currently the group does minimal support of some existing packages. But otherwise we've ported most of the packages we created to the public Conan Index. Of particular relevance is that we organized using the Open Source Collective as a Fiscal Sponsor (https://opencollective.com/bincrafters) == Disclosure, Past As the past is an indicator of the future I thought it important to also include some of the related organizations I've been part of before now. *Redshift Software* I was President of a software development S-Corp that did all kinds of contracting projects during the 16.5 years it operated. We did everything from tools, games, and web sites. It was during the early days here that our need for a build system for the version control system we developed came from and how I came to find Boost. We went on to use Boost heavily during that time. Which necessitated myself fixing bugs across many of the Boost libraries. This is also where I taught myself how to run a corporation, by reading Illinois corporate law books and IRS rules. *Couchworld Games* I was also President of this game development C-corp (minor note, I was "volunteered" for the position in this one and in Redshift). Even though this corp got created to develop some AAA games, we ended up creating some iPhone puzzle games in C++. Which was a rather hard endeavor given the iPhone ecosystem in the early days. And, yes, we used Boost and B2 in the engines we developed for those games. *BoostPro Computing* BoostPro was a consulting company started by Dave Abrahams to support Boost developers by having clients pay for the technical support of their use of Boost and general development for the clients. Some of that work ended up as new Boost libraries. I worked, as a subcontractor, for 3 years alongside Dave, Eric Neibler, and Joel de Guzman. In summary, I've been involved in most aspects of Boost for more than 22 years. == Executive Committee: When I say "Executive Committee" I'm referring to a group that performs actions on behalf of a group. In this case I'm avoiding the "Steering Committee" term as it appears to have additional connotations because of the past use in Boost. I think it's important that I explain what I think how a group (like an Executive Committee but applies to any group claiming an equivalent role) representing Boost developers should operate. For an Executive Committee it is paramount to gain and maintain the trust of the developers. To achieve that, decisions need to have the support of the developers. Actions by an Executive Committee should not come as a surprise to developers. >From the beginning of my interactions in Boost I learned one key fact.. Progress got made by those that acted and obtained buy-in from the Boost developer community. Of the various achievements Boost created early on, the one that made it possible to get such buy-in, has been the community review process. It is a bottom up process that is designed to remove doubt from the ethos of Boost. It is the community review process that we are using now to clarify how Boost moves forward, and hopefully upward. It should be the process that we follow for Boost developers to make decisions about the assets that sustain Boost development. And it should be the results of such a process that the group representing Boost developers accept as binding to make further decisions. I am hopeful that the machinations we are currently following will become the norm. Some have mentioned concerns about conflicts of interest in our governance moving forward. Irrespective of my current inclusion in the proposed composition of the Committee by the Alliance, it is my hope that any future Committee will adopt policies that uses the Boost Community Review process to drive decisions. Any actions the Committee makes, including, but not limited to, its future composition, should have community consensus by the time the Committee votes. It is the only fair, open, and clear way to make decisions. == Inclusivity: As this topic has been mentioned a couple of times I feel like I need to explain my philosophy on this and some related context. I believe that a varied set of ideas and understanding is essential to any life endeavor. As such I believe that keeping doors open to conversation is key in understanding and inclusion. Even though I think that words are important, I place actions above rhetoric. In other words, I think being a decent person is more important than telling others how they should be decent. My philosophy likely stems from learning to live with conflicts in my life. I became an immigrant to the US when I was a teenager. I'm also not an immigrant because I was born in Puerto Rico with US citizenship. English is not my native language. But I am also more fluent in English than my native Spanish. I am a straight man in a field (game development programming) dominated by straight men. I am also Hispanic in a field where they are an underpaid minority. Part of my ancestry is European and originates in Mallorca, Spain and further back in Catalonia. Another part of my ancestry is Native American of the Caribbean Taino Civilization. Even though I came to Boost searching for a build system, that is not what kept me in Boost. And it was not racial, language, biological (I say that one from the perspective of having a name that is often confused as female in the US), theological, or cultural inclusivity that kept me in Boost. It was intellectual inclusivity that has kept me here for more than 2 decades. It was, and in my opinion still is, a community where I can expect an honest consideration and assessment of technical ideas. == Are you knowledgeable about the problem domain? Yes. I have managed for-profit companies. I have helped, and currently help, to manage non-profit companies. I am versed in managing organization assets of those companies. == Proposals: Given all that preamble, below is my review of each proposal. Foundation:: I found this proposal spent most of its wording explaining the ethos it aims to operate within. It is helpful to get that detailed exposition as it has been something that has been missing from the Foundation (and the SC before it) for a long time. What I see in that exposition though is in dissonance with my experience. The mentioned transparency is limited in time, the past two years publishing minutes, and scope, process on how decisions like board membership are made have been lacking. Consensus building is mentioned as a core aspect. But it is unclear how the consensus process is achieved for Foundation decisions that impact Boost. The items mentioned as the actionable parts of this proposal are "Community building", "Improve relevance", and "Adopt governance best practices". Of those, the one that enumerates some steps that apply to the stewardship of Boost assets is the last one. The first three items, as far as I understand, apply to how Boost developers operate and make decisions as envisioned by the Foundation. The fourth and last items pertain to how the Foundation intends to improve its composition with, I can only assume, the intent to increase participation from Boost developers. The fifth item is the only one that directly addresses the aspect of managing Boost assets. Outlining how the Foundation would take control, and possibly ownership, of assets. But it doesn't mention which assets. Is the library source an asset in this model? Who decides which assets? What this proposal lacks throughout is consideration for accountability to Boost developers wishes. While placing all control in the Foundation. This is an arrangement that would require the utmost trust in the Foundation by Boost developers. And given past history I don't see evidence of such a level of trust being merited. Alliance:: The background of the proposal is thoroughly researched and explained in detail. Although there is a fair amount of background information in the proposal I think it can be summarized as "it gives Boost developers control over Boost assets through a Steering Committee". And although this specific proposal is for the Alliance to be the Fiscal Sponsor that is, as we like saying, "an implementation detail". As the control of what happens with the assets goes to the Committee who represents the Boost developers. The proposed Transition Plan recognizes the roles of the various parties and does a good job of remunerating the parties for the work in the transition. The operation of such a Committee and the Agreement match what I know of the requirements for managing non-profit assets. == Conclusion: I support the C++ Alliance proposal to transfer assets to it and to form a new Steering Committee. There are various details to be worked out if the proposal is accepted by the Boost community. For example, the name of the Committee, its final composition, a final contract, and so on. But that's expected, and natural to achieve a structure that the Boost community can grow with. Thank you for reading this far, René

2 1

[cmake] Define CMAKE_PROJECT_VERSION for standalone subprojects
by Lucas Colley 18 Sep '24

18 Sep '24

Dear boost developers, Subprojects like `math` define CMAKE_PROJECT_VERSION in terms of BOOST_SUPERPROJECT_VERSION via: ``` project(boost_math VERSION "${BOOST_SUPERPROJECT_VERSION}" LANGUAGES CXX) ``` This is clearly handy to save a few seconds in the release process, but it means that if one wants to use the subproject standalone (where BOOST_SUPERPROJECT_VERSION is undefined), CMAKE_PROJECT_VERSION is also undefined. This is a problem for me as I am trying to make boost_math a Meson-CMake subproject of SciPy. This would enable us to un-vendor boost_math from SciPy, such that a distro can instead use SciPy with boost_math as a system library. We would only fall back to embedding the boost_math source when it is not installed as a system library. When the boost_math source is embedded, CMAKE_PROJECT_VERSION is parsed to check that we have the correct version to work with SciPy, but we get an error that the version is undefined. This could be solved by defining the version directly in the math subproject instead of in terms of BOOST_SUPERPROJECT_VERSION. The alternative solution of embedding the entire boost source is not suitable for us, since all we need is math. Would it be possible to switch to defining CMAKE_PROJECT_VERSION directly in subprojects? Or is there a more compelling reason to define it in terms of BOOST_SUPERPROJECT_VERSION? Cheers, Lucas — For context: https://github.com/mesonbuild/meson/pull/11730#issuecomment-2351619977, https://github.com/scipy/scipy/pull/21270

3 3

Re: [boost] proposal Multi multidimensional array library
by Andrzej Krzemienski 18 Sep '24

18 Sep '24

śr., 26 kwi 2023 o 23:38 Alfredo Correa via Boost <boost(a)lists.boost.org> napisał(a): > Hi all, > > My name is Alfredo. > I would like to propose this library called Multi for inclusion in Boost. > Multi is a container and views library for (dynamic) multidimensional > arrays. > > The library is available here, > https://gitlab.com/correaa/boost-multi. > > The Boost prefix is purely aspirational at this point, of course. > As I understand the process, the important step at this point is to > find someone(s) to endorse the library and later a review manager. > If you want to be an endorser, please let me know. > > If anyone has feedback or tips to prepare it for a review, please let me > know as well. > I will be at the Aspen CPPNOW conference if someone wants to discuss it in > person. > I am in the C++ Slack channel #boost for discussions as well. > > Here is a link to try it quickly online https://godbolt.org/z/KerbxW6WK. > Hi Alfredo, Thank you for sharing your library. This has been more than a year now, and I am sorry for the delayed response. Thank you for reminding us of it in the slack channel. From this, I gather that the game is still afoot. Recently, it was pointed out in this Mailing List, that it is unfair with respect to the authors to give critical feedback without having studied the proposal, yet I am about to do exactly this. I have only read the introductory part of the docs, as well as the "Comparison with other array libraries" appendix, and my feedback is solely based on that. But you can consider me a good representative of a potential user of the library, who is impatient, and can offer only 5-10 minutes to decide if they want to invest more time in studying the library. This is in the spirit of Roert Ramey's advice: https://www.youtube.com/watch?v=ACeNgqBKL7E&ab_channel=CppCon I personally never needed to manipulate big multidimensional arrays, so I cannot immediately appreciate the usefulness of the library. I need a good introductory part. When I read the high-level description, I immediately think, "it is the same as std::mdspan". The docs say that it is different from the std::mdspan, but then I think, "no, it is the same as std::mdspan". >From the comparison table, I gather that Multi offers both the container and the views (sort of references), and that std::mdspan is only a view. Am I right? The docs say that Multi provides value semantics, but I guess it is not a fair statement. I guess (and correct me if I got this wrong) that the container is value-semantic, but the views are not. That is the nature of the views, that you want them *not* to have value semantics. A fair comparison, should compare Multi's views to std::mdspan. Now, the Standard library has also a proposal in flight to add a container for multi-dimensional arrays: std::mdarray: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p1684r2.html Could you also include it in your comparison? And I would expect that std::mdspan and std::mdarray are treated as one in this case. I read that Multi's types have an STL-compatible interface (range). But this is far from obvious what it means in the context of multi-dimensional arrays. The range/iterator interface was tailored for one-dimensional data structures. There is no obvious generalization to multiple dimensions. I wouldn't even expect a multi-dimensional array to give me an STL interface (whatever that means). Maybe, you mean that the library offers a view where you can see the entire multidimensional array as a long string of values? This would make sense, but if it is the case, I expect the introduction to say exactly this. In the case of std::mdspan, it has been said that it has been tailored to efficiently represent both huge datasets as well as tiny 4x4 matrices. I am not sure if this is the case, but I request that the docs for Multi say what use case they have been designed and optimized for. Does the library only represent dense matrices, or can it also represent sparse data? The term "stride-based". It is not clear to me what it means. I cannot see from the introduction if this library will throw exceptions. The comparison between Multi and std::mdspan in the row "const-propagation semantics" is unfair. I guess you are comparing Multi's container with a view. A view is not expected to propagate constness. So this is the very initial feedback, I hope it helps. Regards, &rzej;

4 5

[Asset Stewardship] About the Beman Project
by Andrzej Krzemienski 17 Sep '24

17 Sep '24

Hi Everyone, The review hasn't started yet, but I think there is no harm in starting the discussion earlier. The Fiscal Sponsorship Proposal from C++ Alliance has the following statement. At the C++Now conference in 2024, the Foundation launched a competing > library collection called the Beman Project, describing it as “a new > initiative separate from Boost that gets back to its original purpose of > improvements to the standard library.” Could perhaps directors of the Boost Foundation comment on their affiliation with the Beman Project? The reason I ask is that my perception of the Beman project, given the scarce information about it online, and the observation that C++ proposal authors prefer to avoid Boost, is "Boost doesn't work, let's start something new". Regards, &rzej;

24 56

Safe C++ and Boost
by Vinnie Falco 17 Sep '24

17 Sep '24

Hi. I am proud to announce that the C++ Alliance has entered into a partnership with Sean Baxter to develop Safe C++: language extensions to provide memory safety in C++. Some of you might have seen the official announcements on various social media sites, and I’m here to provide some more information on how this initiative affects Boost. First, I want to express my appreciation for Sean’s enormous technical abilities, and for his stamina to invest eight years of research and development into Safe C++. I believe that his efforts reflect good philosophical principles for improving the language with memory safety extensions: 1. Safe C++ must be a superset of C++: all existing code must work. 2. Safe C++ must allow controlled opt-in to memory safety: expecting the world to rewrite everything in a new language is not realistic. 3. Safe C++ must be developed using an implementation-first approach: a working model is preferable to just ideas. The partnership with Alliance has three deliverables: research the remaining design problems, complete the Safe C++ Language Extensions proposal for standardization, and implement the Safe C++ Standard Library. The safe library is a set of additions to the standard library providing essential vocabulary types and algorithms needed by users to achieve memory safety. We don’t know that Safe C++ is the final solution for memory safety in C++. Perhaps the required extensions will be so intrusive as to make it effectively a new language. Maybe the language features which allow for zero-cost abstractions are so powerful that they can’t be preserved in ways that are memory safe. Yet there is value in pioneering this design space that Sean has carved out. It is also possible that Safe C++ becomes the winning memory safety story for C++. We at the Alliance believe it is worth taking the chance to find out. Through the relationship with Alliance, the Boost community has a unique opportunity to participate in helping to explore and solve the remaining difficult design problems, and a front-row seat to the latest draft of the Safe C++ proposal which can be viewed here: https://safecpp.org/draft.html If you would like to discuss Safe C++ in real time with other engineers please join the #safe-cpp channel in the Official C++ Language Slack Workspace by signing up here: https://cppalliance.org/slack What does this mean for Boost? There is a tremendous opportunity here for Boost to innovate ahead of the C++ Standard. I envision the scenario where some volunteers will port selected Boost libraries to Safe C++ as a proof of concept. The porting process will surface areas of the proposal which need work. As memory safety is rapidly becoming the defining feature of modern mission-critical software development, the opportunity for Boost to lead in this area may attract the needed revitalization of the project in the form of new volunteers. Please join us in helping to define this exciting chapter of the C++ language! Thanks

5 8

Boost Asset Stewardship Review
by hans.dembinski＠gmail.com 16 Sep '24

16 Sep '24

I vote to accept the proposal of the Boost Foundation. I am neither affiliated with the C++ Alliance nor with the Boost Foundation. I am the developer of the Histogram library, which sees a lot of use in the scientific community. My personal values are aligned with the Boost Foundation and its supporters. My observation is that the C++ Alliance uses money to gain influence over this community, for example, by paying some community members to work on projects, and through its donations into the infrastructure. I want Boost to be a non-hierarchical community based on volunteer work, inclusivity, transparency, and consensus. The community is developing away from this ideal, as the C++ Alliance has taken an increasingly dominant role. While my decision here may not change that trend, I cannot support a proposal which would further increases their influence. Hans

3 2

On how to write good documentaiton and why
by Andrzej Krzemienski 16 Sep '24

16 Sep '24

Hi Everyone, While reviewing a Boost candidate library, I re-watched Robert Ramey's advice on how to write library documentation, from CppCon: https://www.youtube.com/watch?v=ACeNgqBKL7E&ab_channel=CppCon https://www.youtube.com/watch?v=YxmdCxX9dMk&ab_channel=CppCon These are so great talks, and so much practical, wise and appealing advice. Whenever my colleagues ask me for advice on how to write documentation, I give them these links. I also follow the advice ever since I watched the first video. Robert, thank you for them. I believe that this is a valuable Boost asset, and should be listed along the Boost Software License and the Boost Review Process. I hope that our documentation (old or new) will mention it in a prominent place, much like the docs mention the great article "Exception-Safety in Generic Components" by Dave abrahams. Regards, &rzej;

1 0

Page on the website clarifying Export Status
by Glen Fernandes 15 Sep '24

15 Sep '24

Every now and then (most recently, two days ago), I get a question asking if we have an ECCN in compliance with US export control laws. ECCN is an Export Control Classification Number. (More details at the Bureau of Industry and Security website : http://www.bis.doc.gov/ for anyone interested). We fall under "Not Controlled", so we do not have such a number. (Ion, as a heads up, you will probably start getting these kinds of questions now too). We should probably put this somewhere on our website. FAQ or a page on itself. Any concerns or comments? Glen

1 0

[Asset Stewardship] Andrzej's review
by Andrzej Krzemienski 15 Sep '24

15 Sep '24

Hi Everyone, This is another review in the context of the Boost Asset Stewardship proposal(s). I am not affiliated with either the C++ Alliance or the Boost Foundation, although in the past I talked with the Alliance about the potential compensation for my contributions to Boost, and I represented the Alliance in one WG21 meeting, in Rapperswil. I maintain Boost.Optional library, try to contribute to all Boost reviews, and have managed the review of Boost.SafeNumerics library. I consider myself a Boost Developer. The subject of the review is, which legal organization formally owns the Project's assets, and who actually manages them. But the questions I, as many others, am trying to answer is: * What is going to be the shape and the popularity of Boost libraries? * Where will the funding come from? * What will the Boost community look like? * To what extent will the Boost community be in control of things? The tricky part is that the goal of the Boost Foundation in the past, as well as the future goal of whoever will manage the Boost assets is so that the developers can focus on the development, and need not study the administrative and financial stuff. Yet it is the developers that need to make the decision regarding the administrative and financial stuff now. One thing that I didn't have to pay attention to in the past, and now is becoming clear to me, is that in order to be able to host a host of libraries, test them continuously, improve the infrastructure tools, and build new tools (like the one for documentation), costs huge amounts of money (by my standards). It is my understanding that this cost has been primarily covered by the C++ Alliance. But it is also my understanding that this happened under the Boost Foundation's government, and theoretically the C++ Alliance could continue to make financial and technical contributions under the government of the Boost Foundation. I also hear that this is practically impossible, for reasons that are not all clear to me. I understand that there are fundamental differences in philosophy. The Boost Foundation has the volunteer model, where people devote their private time as their lives permit, and that the C++ Alliance is an organization with huge funds, and the capability to employ people. I also understand that it is a risk for the C++ Alliance to invest huge assets in the Boost project, knowing that ultimately the efforts can be torpedoed by the decisions of the Boost Foundation. I am not saying that this is or has been the case. I am only pointing out the obvious consequences of the mistrust. The Boost Foundation is volunteer-driven. This means that people work on what is deer to their heart, and if something is not deer to anybody's heart, it may not be done, even if important. The volunteers can only put as much effort to their work as their private life permits. This means sometimes they have to give up. The effect might be that a volunteer-based organization may appear unreliable. On the other hand, volunteer work inspires more volunteers. I was surprised to find that the Boost Foundation's, as it is today, primary goal is not to support Boost's interests: it supports many initiatives, Boost being one of them. I was misled by the name. People, including myself, have pointed out that the support for the Beman project is somehow in conflict with supporting Boost. But having thought more about it, I no longer feel this way. I am now inclined to think that the Beman project is the best thing that could happen to minimize the damage caused by the current process of standardizing libraries in WG21. So if there is any glitch in the Boost Foundation, it is the support for some proceedings in WG21. This is because WG21 innovates and experiments, instead of standardising the things that work. I think the Boost Foundation has been doing a good job at steering Boost. If people feel that "they are doing nothing", this might be the indication of the job done right: Boost is rolling, the lights are on, the Foundation is not getting in the way of the developers. Most of the job done is invisible. The question is, can we still improve if we adopt the Fiscal Sponsorship Agreement from the Alliance. I understand that the Agreement gives the Alliance the sense of stability: that the efforts that cost years and millions will be integrated. This would help secure the development of essential components that we need: * the modularization * the platform for communication that is open for the young, while not discriminating the old (like myself) * a tool that helps produce documentation. Except for the first, I do not think they can be achieved without a substantial financial effort. Risks: * With this huge and single source of income, we will be looking more like a company than a volunteer organization. * It is likely that because of this Boost will not attract new volunteers * It is likely that no-one else will feel the need to sponsor Boost. But even if some of these risks were to materialize, the value of having a tool for writing documentation for C++ libraries is so huge: it goes beyond Boost. My concern from a different level is that after all the chaotic and unpleasant (mis)communication in the Mailing List, I am left with the impression that the C++ Alliance is ready to break the established rules in order to achieve the goals. This may be a deeply unfair statement, but I can't help it: this is what the shreds of information that I receive suggest. The proposed Agreement attempts to secure the Boost project against the situation of an irresolvable conflict, but no agreement can secure your interests when the agreements are not respected. During this review period I have heard late but honest explanations from the Boost Foundation members that explain their actions and show their motivation, and I find them credible. I do not believe I have heard the account from the C++ Alliance that would help understand what motivated the organization to act the way they did. One last concern is that I am not comfortable with the fact that the proposed Fiscal Sponsorship Agreement re-uses the term "Steering Committee". As indicated in other messages, the Boost Foundation *is* the Steering Committee, or rather continues the tradition of the Steering Committee with the same people onboard (not all, obviously), and with the same ideals. In order to honour them and in appreciation of their work, I think the new setup should not intercept this name. Regarding the question of attracting or repelling new contributors, I find it hard to believe that the enforced Code of Conduct could have a significant impact on the results. In my opinion, what could have a bigger impact is when Boost becomes modular, people can afford to use it more in more contexts, appreciate it more, and some of them decide to contribute. Regarding the Foundation's counter-proposal. I do not find anything material in it. I read it as "let's leave the things as they are, but let's enforce the CoC and increase transparency and efficiency". As I said, I cannot see how the enforced CoC could make a substantial difference. Regarding the efficiency and transparency, I do not find anything substantially wrong with them today: they are good enough. Today we are facing a crisis, but other than that I think the Boost Foundation is doing a good job. The Boost Foundation also mentions the modularization and the new communication platform, but even the Foundation members admit they do not believe that making such big projects would work with the Boost's consensus-based philosophy. In closing, I would like to say that I am grateful to the members of both the C++ Alliance and the Boost Foundation for your contributions to the Boost project and community. I have certainly benefited from your work, in many ways. I recommend accepting the Fiscal Sponsorship Agreement from the C++ Alliance, as I see the potential in it to significantly improve the situation of Boost, and other good libraries out there (I mean the new documentation tool), while recognizing that this is a risky decision. Regards, &rzej;

2 1

Boost Asset Stewardship Review from Ruben
by Ruben Perez 13 Sep '24

13 Sep '24

DISCLAIMER: I'm a C++ Alliance employee Hi all, I'm the author and current maintainer of Boost.MySQL. I'd first like to thank both the Boost Foundation and the C++ Alliance for their contributions and efforts, especially when done in their free time. On the technical side, I particularly appreciate the infrastructure contributions the C++ Alliance has made. The Drone CI has been really important for me even when I was a volunteer, as it's fast and supports Windows Docker images. I also appreciate their efforts regarding documentation, as I share the need to update Boost in this aspect. Of course, their recent sponsorship regarding Boost.MySQL has allowed me to develop the library much further than my otherwise scarce free time would have allowed me. I think the C++Al proposal is good, as it will allow other authors like me to also benefit from infrastructure improvements like the ones I mentioned. C++Al people are pretty technically enthusiastic, which I also like. The concern of letting too much of Boost's decision power in a single organization's hands seems legit. However, the proposal seems to take this into account, proposing several measures to mitigate the risk, with a Steering Committee composed of respected Boost developers. I also support adding Peter and Glen to the committee. I also appreciate the contributions that the Boost Foundation members have made to Boost, and would like to thank them for that. I'd like to echo a point made by others in the mailing list throughout this discussion and also somewhat reflected in The Boost Foundation's proposal, about mailing list friendliness to newcomers. When I first reached out to evaluate the potential usefulness of what would become Boost.MySQL (https://lists.boost.org/Archives/boost//2020/03/248301.php) I received a couple of really discouraging comments, which almost made me abandon the idea. These comments were based on the (somehow understandable) misconception that my library was a wrapper around the official C API. Thanks to other people's support (Richard, Chris, Vinnie and some others, IIRC) I managed to move forward. But it could have not been the case. As a community, we could try to improve instances of this to make things better for newcomers. That said, I think the C++ Alliance proposal moves in the right direction, so I vote to ACCEPT it. Thanks, Ruben.

8 11

The Future of Boost Governance
by Dave Abrahams 13 Sep '24

13 Sep '24

I'm writing to represent the spirit in which Boost was founded and in which we ran it, as a community, up until 2013. I realize the review is nominally about asset stewardship, but IIUC the more fundamental change being discussed is about governance, not who holds Boost's property. Before I moved on to other things, I participated in setting up a steering committee that was supposed to step in and make important decisions when Boost's default "community-based leadership and decision making" process got stuck or was otherwise inadequate. That body, I gather, evolved into the Foundation board. For some purposes, that governance structure has worked, but when it comes to managing Boost's assets, it seems the ball was dropped, and the Foundation did not self-correct. Therefore, I very much understand why one might want to transfer Boost governance to an organization with more apparent energy. All that said I am deeply concerned about recent actions by the C++ Alliance. Please correct me if I'm misinformed about any of this, because as I've said I've been out of the loop. It is my understanding that the Alliance did not communicate to the Foundation or publicize its efforts to gain control of the boost.org <http://boost.org/> domain name. Effective or not, the Foundation is the nominal governing body for Boost, and coordination with the Foundation would have been the appropriate, aboveboard course to take. It is my understanding that despite an agreement to coordinate the launch of a new Boost website with the Foundation board, the Alliance decided to launch boost.io <http://boost.io/> in parallel with boost.org <http://boost.org/>. That move is problematic for all the same reasons. It also creates confusion for the user community about where the real Boost is. These aggressive and unilateral actions seem to be at odds with the spirit of Boost and to be harmful to the coherence of its community. IMO it's very much to the Foundation's credit that they did not respond in kind, but instead opened a discussion about Boost's future governance and offered to abide by the community's decision. That is what I'd expect from a group that truly had Boost's interests at heart. All that is great but it does seem very wrong that the conversation should be prompted by actions like the above, and for me, any outcome that transfers Boost governance to the instigators of those actions compounds the problem. It saddens me greatly that a rift exists between the Alliance and the Foundation, because the energy and commitment of the Alliance members is admirable, and communication here on the mailing list looks like it has been productive. My ideal outcome would be to repair whatever is needed to make the Foundation work as a governing body, and to repair the relationships so that Alliance members can continue to make great technical contributions without feeling like the Foundation is holding up their progress. I'm sure that would be asking a great deal of the participants on both sides, but that's what I'd like. It seems to me any correctives that would result from a governance transition could equally well be applied to the Foundation itself. - Dave

6 6

Domain Transfer Update
by Kristen Shaker 13 Sep '24

13 Sep '24

Hello, I wanted to give everyone an update regarding what is happening with the boost.org domain. We are working with the lawyer representing the Dawes estate to transfer control. However, Beman Dawes was the only one with the credentials, and the transfer process without them is onerous. It may take many months. We intend to continue to provide updates. Warm Regards, Kristen

10 11

Asset Stewardship Review - Halfway mark
by Glen Fernandes 12 Sep '24

12 Sep '24

Everyone, We are halfway through the review period. Thank you to everyone that has participated so far, even if you haven't contributed a review yet. If anyone has yet to submit a review because they are unsure of how to format it, or what you can contribute, hopefully the responses thus far have helped inform that. If not, then I would suggest starting with a vote and your reason, and we can elicit additional information with follow up questions. So far, nobody that has sent me any questions or feedback privately, has expressed that they would like to post a review but don't know how. I have yet to compose (or source) answers to the last set of questions I received, but I will do that this Saturday. Glen

1 0

Asset Stewardship Review
by Vladimir Prus 12 Sep '24

12 Sep '24

Hi, I vote for the C++ Alliance proposal. Right now, my contribution to Boost is limited to accepting small PRs for the program_options library, I don't expect to be very active in the future, so my vote should be suitably discounted. On the other hand, I wrote one library, contributed changes for some others, and worked on building/testing infrastructure, so probably know something. I have no affiliation with either party, though I criticized Boost Foundation before. Many open-source projects have solved the matter of asset management and financial support without much drama. For example, there is the LLVM foundation ( (https://foundation.llvm.org/) which pays for infra, and sponsors developer meetings. There are 9 people on the board, and their bios all mention LLVM contributions. There is a public process to nominate new board members candidates (the current board votes on them, though). The activity of the foundation is fairly visible. There's also the Apache Foundation (https://www.apache.org/) It hosts a lot of projects, and committers run each one. Matters are resolved by committer vote, new committers are added by vote, and inactive members lose their commit/vote privileges. The foundation itself provides resources, like magic garden gnomes. Probably, with a bit more goodwill and introspection, we could have worked out the details and reached the level of those examples. But, we saw divorce paperwork sent in public, and both parties have a long list of grievances, so here we are, deciding who gets the custody. Boost Foundation, in my opinion, has a real identity and credibility crisis. Originally, in the steering committee times, it consisted of project founders, who were active in the project, and contributed lots of hours and probably personal money, while preferring consensus for all decisions. It gradually changed, and these days, Boost Foundation has largely checked out and consists mostly of people privileged enough to travel to Aspen and other conferences. Still, it occasionally issues decrees for the project to follow. Consider the recent events. There was a decree to stop working with a large sponsor. Per meeting notes, 7 people met to make the decision. I see only 2 with obvious connections to the project. Kristen's post with the announcement was her first-ever post to the list. The board members were not nominated, voted, or announced on the list. Despite many raised questions, foundation members had no timely answers. Even during this crisis, most members did not say anything. And then, just today, one member has it was not a degree, but a recommendation and the alliance can still sponsor everything. That's a clear failure. Maybe it would be OK if the foundation provided vast resources, and let developers decide, Apache-style. But right now it's only paying for the webserver. (I am unsure whether that's the foundation, as opposed to a generous foundation member using personal funds). There are no IT resources to keep the server up-to-date, no money to pay for CI/CD and downloads, and official filings merely say "less than $50K of income per year"). Finally, the fact that boost.org domain ownership remains unresolved even after it already expired couple years ago illustrates the lack of time/interest. The foundation's proposal is weak, brief, and seems hastily written. It does not acknowledge or address the issues above. There's no significant revamp of the board, there's no plan to to procure funding, and there's no plan to obtain IT resources. Instead, it proposes a few other things that might be good. However, those things can be decided on the list. It does not require that the foundation holds the assets. Finally, the proposal does not mention the "Beman Project" at all. It's not clear how the foundation plans to support the Boost project, while simultaneously working on an almost identical one. (I wonder if this proposal was intentionally written to lose, and move on) The C++ Alliance, organizationally, is not much better. Its board is Vinnie and his friends. As an extra plot twist, one member of the alliance board was previously on the foundation's board, and at least partially responsible for the current situation. But, things take a dramatic turn after that. The alliance is way more active in the project. Two board members are active contributors. It employs other contributors. There are quarterly blog posts from employers explaining what they have done. There are "transparency reports" about overall activity. That's easily 10x more transparency. They also have considerable financial resources. The last IRS filing claims over $2M per year. There are full-time employees and there is no doubt that they can handle Boost's relatively simple infrastructure. The alliance proposal is fairly smart. It proposed essentially the Apache model. In turn, that means we no longer have to be concerned about the alliance's board - the arrangement lets committers decide everything, while infrastructure just magically works. I do, of course, have some concerns about the alliance. It is sponsored by Vinnie himself, while the foundations I mentioned above have more diverse income sources. Also, some people might consider voting for the alliance as supporting Vinnie personally, or even taking his side in some outside-of-Boost conflicts. (Obviously, it's not). Alliance, at times, has too much money. I doubt that a "modern logo" is at all necessary, seems like a distraction. The estimated costs for the new, still essentially static, website would seem sufficient to run a few AI startups. I am worried that any change in the financial situation will leave us with way too expensive infrastructure. Like, the current server can be sponsored by literally a single developer. The "new website", at $10K per year, is not so much. At the end of the day, I don't see any choice. The Boost Foundation, as an organization, and as individual board members, made a lot of contributions, but as of 2024, there appears to be little financial and human resources, and no willingness to work with the developers. The C++ Alliance, on the other hand, already pays most of the bills and has proposed a schema that will empower the developers. I think others already commented on the details of the agreement. My only proposal/condition is that the members of the new Boost Steering Committee be provided with access to all relevant IT resources (DNS registrar, DNS hosting, any cloud providers) and that they meet with the alliance periodically, like twice per year, and verify that all the access still works. We want to make sure that in the case of any emergency, we're prepared. Thanks, -- Vladimir Prus http://vladimirprus.com

3 2

Boost Asset Stewardship Review from Andrey
by Andrey Semashev 12 Sep '24

12 Sep '24

[Warning! Long post ahead!] Hi, This is my review of Boost asset stewardship proposals from The Boost Foundation (the current governing organization) and The C++ Alliance. I. Are you knowledgeable about the problem domain? ================================================== Not particularly. Although I can probably consider myself an old-timer (I think, I joined the mailing list back in 2007; at least my archive dates back that far), I have never been privy to Boost infrastructure and management details. The only information I know is what was published on the mailing list (ML). I have also never managed a company or organization outside Boost. I am neither a lawyer nor financist, and English is not my native language, so I may misunderstand some of the information given in the proposals. Sorry if that's the case. However, as a Boost library maintainer and user, I am interested in the Boost project's bright future. Specifically, the future where I'd be willing to continue using and contributing to Boost. While this may sound selfish, my hope is that my contributions will also make Boost more useful to others. So, my review will be written mostly from a maintainer's and user's perspective rather than someone knowledgeable in the problem domain, which is primarily asset management and legal relations between organizations. I am not affiliated with The C++ Alliance or The Boost Foundation. II. The problem statement ========================= In order to evaluate the proposals, I will first state the problem, as I understand it. Then, I will see how each of the proposals addresses it. I will separate the problem description into three aspects: 1. Boost popularity decline. As stated in both proposal documents, Boost popularity has declined in recent years, based on metrics such as the number of posts in the ML, the number of submitted libraries or the number of git commits per year. The C++ Alliance proposal provides the relevant data in Appendix 2. My personal perspective is that *volunteer participation* in Boost is indeed reducing. Here, by volunteers I mean contributors that are not staffed by The C++ Alliance and contribute their work independently. It appears like Boost "went out of fashion" and going though a Boost review is too difficult and time consuming for newcomers, and so they are picking easier alternatives to publish their code and ideas and gain recognition. In doing so, new developers seem to be willing to trade the quality of their solutions for popularity and quick gains. I'm not entirely convinced that this lack of participation is caused by how modern our website looks or how often we post news items on social media. While these things do matter, I suspect the fundamental issue is that newer developers simply don't want to bother with the review process and responsibly maintaining code afterwards for various reasons. I find this tendency extremely sad and worrying, even more so since it is not unique to Boost. However, I do not think we can say that Boost *usage* is declining. From the data presented in The C++ Alliance proposal, it looks like the number of Boost downloads is growing, so much so we had to contract a CDN provider to serve them, as well as introduce GitHub downloads. Athough I imagine large portion of these downloads are automated (e.g. CI jobs), even that interpretation speaks in favor of a growing user base (more CI jobs probably means more projects are using Boost). I suppose, it should not be surprising that there are more users than contributors, but I still think it is worth pointing out that Boost popularity is not declining, as it may appear from some online forum comments. 2. Boost asset management. There were several instances of poor management of Boost assets, such as: - The boost.org domain, which was nearly lost to an auction. - The website. The current website is mostly unmaintained, and there is no (public) plan of modernizing it. The new proposed website is rejected by The Boost Foundation and remains "unofficial" at boost.io. - Social media accounts. The official @Boost_Libraries account on X is dormant, and the access to it is restricted from members of The C++ Alliance who have volunteered to maintain its activity. Which resulted in creation of a separate, "unofficial" @BoostLibraries account. - The wowbagger server that is running the current website and mailing lists is outdated and have seen hardware failures that resulted in data loss (as noted in The C++ Alliance proposal). The software stack on the server is also outdated and cannot be easily updated. - The Boost logo, for which, apparently, The Boost Foundation doesn't hold the appropriate license. The duplicate website and X account are especially bad for users, as it causes confusion as to which one is genuine and the true source of information. They are also very similarly named, so much so that one might question their legitimacy. I'd like to point out that the issues with Boost downloads, when we exceeded the free downloads quota, were largely solved with help of The C++ Alliance and The Boost Foundation (specifically, I believe, Sam Darwin and Glen Fernandes). This is an example when the two organizations (or perhaps, individuals thereof) have collaborated to solve the immediate problem. Many thanks to everyone involved. 3. Lack of communication with asset management body. I think, many of Boost community were unaware of the asset management issues listed above until recent discussions on the ML. I personally did not know about the issues with boost.org, data loss on wowbagger and licensing issues for the logo until recently. I believe, some of these issues could have been solved sooner if they were communicated on the ML by The Boost Foundation. Furthermore, even after the issues have become known, there were, depending on the specific asset, little to no communication from The Boost Foundation as to (a) whether the problem is real and (b) what is the proposed plan on addressing it. Basically, The Boost Foundation took a reactive stance in regards to The C++ Alliance actions that it (the Foundation) perceived as hostile. III. Evaluation of The Boost Foundation proposal ================================================ My overall impression of the proposal is that it lacks substance and in some ways is not aligned with Boost traditions. Following is my analysis of how the proposal tackles the stated problem. 1. Boost popularity decline. A significant portion of the proposal is titled "Our Community Values". I'd like to note that this seems to implicate that these values are those of the Boost project community rather than those of The Boost Foundation. This is further reinforced by the contents of the "What we propose" section, which stem from these stated values. I do not believe this implication is correct. In fact, I do not see these values listed anywhere on the www.boost.org website or the "Proposal for a C++ Library Repository Web Site" (https://www.boost.org/users/proposal.pdf) While some of the values listed in the proposal are aligned with the spirit of the Boost project, others are not. In particular, the "Inclusivity" section discusses representation of women in The C++ Alliance staff and the proposed Steering Committee. This is entirely irrelevant for the purpose of Boost asset management and looks like a cheap stab at the opponent. The document then goes on to propose to "make an active effort to get those historically underrepresented to participate". I think, this is an entirely wrong approach to the problem. Boost has never been about representation of women, or any other social category for that matter. The relevant portions of our guidelines are this: A guiding principal is to encourage wide participation and interaction. Get people involved, in newsgroups, mailing lists, as peer reviewers, library contributors and maintainers, and as moderators and webmasters. And, of course, as library users. (https://www.boost.org/users/proposal.pdf) Boost libraries are intended to be widely useful, and usable across a broad spectrum of applications. The Boost license encourages the use of Boost libraries for all users with minimal restrictions. [...] Boost welcomes and thrives on participation from a variety of individuals and organizations. (https://www.boost.org/) Notice that nowhere in these lines specific social groups are mentioned. I'd like to think this is intentional. The only criteria mentioned is talented people willing to contribute their time, ideas, code and effort to various areas of Boost, an open and widely useful collection of C++ libraries. Martians included. As soon as you substitute this criteria of technical merit with inclusivity/representation agenda, you are taking away from the technical quality of the community and bringing in unhealthy atmosphere of inequality. Ultimately, this harms the project as a whole. I find this unacceptable. Another related suggestion made in the proposal is introduction and enforcement of "a strong code of conduct". Also, "make an active effort to improve behavior on the mailing list". The proposal does not go into details as to what the "strong code of conduct" might look like, or in what way the behavior on the mailing list needs to be improved, but given the inclusivity agenda I have to make some uncomfortable assumptions. Specifically, that the suggested code of conduct is intended to promote the agenda and could potentially be used to prosecute those who disagree. I know I have commented on this topic earlier, but I feel compelled to make this part of my review. I find this sort of code of conduct, as well as using it as leverage on people unacceptable. I do not want to see Boost descending into curating people's opinions (let alone their behavior outside Boost), segregation, preferentialism and political infights. I think, our current discussion policy strikes a good balance between defining what's considered unacceptable behavior and leaving enough freedom to keep the discussions vibrant and productive. I don't remember a case when we needed something more strict, and I don't remember us needing to enforce it onto someone either. Lastly in this problem category is the suggestion to "consider adopting a modern communication platform, such as discourse". There was a discussion on this topic on the ML (unfortunately, threading was broken at the time, but you can search by "Replacing the ML with a forum" in the title), which showed a strong preference for ML in the community. I do not think switching to a web forum solution, especially one that does not support threading, would be in the best interest of the community. It may attract more new users, but it will also push away active developers. New users are not necessarily going to replace the maintainers who are going to leave. Personally, I'm not seeing myself switching to a web forum. If the suggestion is not to switch but to bring up a forum *in addition* to the ML, this is also not a good solution, IMO. If the two platforms are independent from each other, this will result in community fragmentation, which I would like to avoid. In particular, this would make review discussions problematic, assuming the review would happen both on forum and ML. I'm not against a forum interface per se, but I think it should integrate with the ML, so that people using both interfaces are able to communicate with each other transparently. Which is something similar to what The C++ Alliance is working on. 2. Boost asset management. I feel that this aspect of the stated problem is not addressed by the proposal nearly at all. Which is disappointing, since I was hoping that this aspect would receive the most attention of The Boost Foundation given the recent communications on the ML and direct requests from the community. The proposal mostly states that The Boost Foundation retains ownership of the assets and undergoes internal organizational changes so that each asset is associated with a given member of the Foundation. While personal responsibility and staff rotation are good, this doesn't really address the issues at hand. For example, what is the proposed resolution with the website? The logo? The wowbagger server? And so on. These questions remain unanswered. 3. Lack of communication with asset management body. Out of the three problem aspects, I got the most positive impression on this one from the proposal. I do like the idea of introducing key officers on the ML, as well as open board meetings. On the latter, I would like to amend so that online attendance should be possible, as not everyone lives near the location of the board headquarter, or wherever the meeting takes place. I would also like to see periodic reports on the ML (e.g. once a quarter) on what was done in the given period, what are the current problems, who is working on them, what was done and what is the plan going forward. I would like to see more active responses from The Boost Foundation on direct requests from the community. Perhaps, set up a public issue tracker so that people are able to report problems and track their progress. This might be as simple as a GitHub project with an issue tracker and a task list (https://docs.github.com/en/get-started/writing-on-github/working-with-advan…) 4. Other thoughts. The proposal suggests "Complete the CMake migration". While I'm not opposed to continued work on CMake support, I do not think it is The Boost Foundation's role to declare tasks like this. It is a decision made by the Boost community, and the work is done by library maintainers. Same for "Consider putting the monolithic distribution in maintenance mode and require new libraries to be self contained". This is not a decision to be made by The Boost Foundation; it must be discussed on the ML first. To this end, I do not think requiring all new libraries to be self-contained (that is, not have any dependencies) is realistic or a worthy goal to pursuit anyway. IV. Evaluation of The C++ Alliance proposal =========================================== My overall impression is that The C++ Alliance proposal is more substantial and comprehensive, which I like. 1. Boost popularity decline. The proposal describes the work that The C++ Alliance has been doing to improve participation in the project. I'm assuming, the proposal implies that the work will continue if the proposal is accepted. In particular, these items were mentioned: - The new, "refreshed" website - A more active X account, with a new image art design - A C++ Slack workspace, which is used for Boost-related chat-style communications - Updated mailman+hyperkitty ML backend in development which will offer a web forum-like interface for the ML - Marketing materials and merchandise distributed on CppCon Those are all very welcome endeavors, especially those which improve accessibility and communication between people. I think, improved communication is a key element of improving public image of Boost and bringing in new contributors - perhaps, more important than the refreshed "looks". As I said in the problem statement section, I think the most deterring factor for potential library contributors is the necessity to undergo a Boost review and then maintain the submitted library. Some developers who target the C++ standard perceive Boost as an unnecessary effort that can be avoided. I'm not sure the above measures will help overcome this perception, but at least they should make Boost more accessible to contributors offering help in other ways, e.g. by providing user feedback and patches. I think, the only party who can improve the situation with the straight-to-standard libraries is WG21, which is out of our hands. What Boost can do is maintain the high quality bar, even if it means less volunteers than we'd like. Besides attracting more volunteers, The C++ Alliance is sponsoring development and employ engineers working on Boost. On one hand, this makes things done and provides another steady flow of contributions, especially in the unpopular areas, like documentation updates. On the other hand, Boost is increasingly becoming controlled by The C++ Alliance, where the majority of roles are fulfilled by the Alliance's employees. There is a saying in my country that can be translated as "the one who dines a girl also dances her", which basically means the one who does the work should also reap the benefits from it. I suppose, it's fitting, but I would still prefer Boost to remain an independent project. This is actually my biggest concern with The C++ Alliance proposal - it further increases control of the Alliance over Boost. 2. Boost asset management. The core of the proposal is to transfer ownership of the Boost assets to The C++ Alliance, to be managed on behalf of the newly created Steering Committee, which is supposed to be formed from Boost community members. In the past, The C++ Alliance have demonstrated that they are willing and able to solve issues with Boost infrastructure and assets. Specifically, to address the aging website, a new one was (and still is) developed, to fix archive downloads a CDN provider was contracted and so on. And although I have reservations about the new logo usage terms and looks, it also exists as a solution to the licensing issues with the old logo. So clearly, this demonstrates that The C++ Alliance is capable of maintaining Boost assets in good condition. However, The C++ Alliance is still an external entity, which is funded by a single individual, Vinnie Falco. This poses risks associated with possible funding issues and changing directional vision for The C++ Alliance and by extension, Boost. The first risk may be mitigated by finding other sources of income, such as donations and merchandise distribution, which, I believe, was the source of funding until now, with The Boost Foundation. The second risk is supposed to be mitigated by introduction of the new Steering Committee, which should represent the Boost project community and define "the technical, artistic and philanthropic direction" of the project. This last part I would like to investigate further. In the Fiscal Sponsorship Agreement (FSA) draft in Appendix 1 of the proposal, two Committees are mentioned. The Current Committee, as I understand it, is sort of a bootstrap for the Steering Committee, and its members are listed in the FSA. I am not sure why the Current Committee is needed, and why is it not possible to form the Steering Committee from the start and only reference it in the FSA. Maybe there's some legal reason to it that I'm not aware of, but it looks like a superfluous entity to me. Another point is that in the list of members of the Current Committee, two of the three members are also members of The C++ Alliance. The FSA does not outline the decision making process in the Current Committee, but strangely does so for the Steering Committee: All decisions of the Steering Committee shall be made by simple majority. This raises two issues. First, if the Current Committee's decision making process is the same then The C++ Alliance has the majority vote in the Committee. I'm not questioning the integrity of the proposed members of the Current Committee, I have nothing but respect for each of the individuals, but I would still prefer if The C++ Alliance didn't have the deciding majority on the Committee. Someone on the ML proposed to include Glen Fernandes and Peter Dimov in the Current Committee, and I support this nomination. Furthermore, I would like the similar problem with the Steering Committee to be mitigated as well. One option is to amend the mechanism for picking members to restrict The C++ Alliance presence in the Committee to less than majority of members. Another option might be to involve the community in the member election, e.g. by holding a vote for candidates. In any case, the goal is to ensure that the Steering Committee represents the Boost project community rather than The C++ Alliance. The second issue is that I find it surprising that FSA is defining the decision making process in the Steering Committee in the first place. It would seem to me that the Steering Committee should have its own bylaws and should decide on how it operates internally, and that has nothing to do with FSA. As long as the Steering Committee's decisions go in line with the FSA, it should not matter how these decisions are made. I'd like to note that I have no preference for the Steering Committee's decision making process; my issue is not with the "by simple majority" part. Although there should be a tie breaker, if the number of members is even. Another thing that bothers me is that The C++ Alliance reserves the right to appoint members of the Steering Committee to bring its size up to three members. I realize that this is supposed to be an emergency plan of sorts, but it seems wrong that The C++ Alliance is making the pick. It would seem, the self-preservation plan should be in the Steering Committee's bylaws, and The C++ Alliance should not be acting in its place. Lastly on this topic, the last part of this sentence seems controversial: Authority to manage the technical, artistic and philanthropic direction of the Project and the program activities of the Project is delegated to the Steering Committee as defined in §6, subject at all times to the direction and control of Alliance’s Board of Directors. It might be my poor understanding of the legal wording, but it looks like this suggests that the Steering Committee is operating under control of The C++ Alliance's Board, which contradicts with the first part of the sentence. Either the Committee decides on the Project's direction, or it is controlled by the Alliance and then it is the Alliance who actually decides on the Project direction. My preference would be the former, in which case this sentence should probably be amended. I would like to comment on the section 8 of the FSA, "Termination". I'm not familiar with the US laws, but do the timeouts for searching for a Successor allow for registering a new 501(c)(3) entity for the purpose of passing the assets to it? The way the section 8.d "Termination Without a Successor" is phrased implies that the assets could potentially be destroyed or otherwise made permanently unavailable to the Project. I'm wondering if there is a better solution, like creating a new non-profit for the purpose of passing it the assets. I admit I'm completely clueless in this domain, I'm just looking if the Termination terms could be improved for Boost. Especially, in the case if The C++ Alliance is no longer able to fulfill its sponsorship. 3. Lack of communication with asset management body. The C++ Alliance members already post periodic reports about the Alliance's activity, and I hope this initiative will continue if the proposal is accepted. Alliance's members are also active on the ML, which is very welcome. So, in the communication department The C++ Alliance has a good track record already. One instance where the communication did fail was the attempt to purchase the boost.org domain from the Dawes estate. I feel, this matter could have been handled better. At the very least, the community could have been made aware of the situation with the domain name and the planned resolution. I can understand how this buyout attempt could be interpreted as a hostile action by The Boost Foundation, and The C++ Alliance (and Vinnie Falco in particular) should have known this would be the outcome. If the proposal is accepted, I would like to ask the Alliance to be transparent about their planned and ongoing activities wrt. Boost assets to avoid situations like this in the future. Doing things like buying the domain name behind everyone's back is not acceptable. In fact, this should be straight prohibited by the terms of FSA, as the Alliance is supposed to act on behalf of the Steering Committee when it comes to Boost assets. Lastly, the suggestion I made in The Boost Foundation proposal review regarding GitHub tasks and issue tracker might be relevant here as well. V. Conclusion ============= Given that The Boost Foundation proposal lacks substance on the asset management part, leaving many questions unanswered, and is taking what I consider a completely unacceptable direction on the community engagement front, I vote to REJECT The Boost Foundation proposal. I understand there likely won't be a second round of review, but if there was, I would have liked to see a more constructive proposal that is more focused on the problems at hand and proposed concrete solutions for them. Where the opponent offers a solution, you should be offering yours instead of stabbing the opponent. I find The C++ Alliance proposal closer to what I would like to see in Boost. On The C++ Alliance proposal I vote ACCEPT WITH CONDITIONS with a single condition being to ensure that the newly created Steering Committee is able to make decisions and operate independently from any possible leverage from The C++ Alliance, in the interests of the Boost project. The specific concerns I have on this front are described in the proposal review. I'd like to thank The Boost Foundation and The C++ Alliance for putting forth their proposals. I'm sure they put a lot of work in it. And I'd like to thank Glen Fernandes for managing this review, which surely is a difficult and responsible task. And if you read this far, thanks for your time and patience. :)

4 6

A history of the Boost Foundation
by Zach Laine 11 Sep '24

11 Sep '24

Dave Abrahams and Beman Dawes put up the initial money for BoostCon (which has since been renamed to C++Now) in 2007 (or maybe 2006?). This was something of a risk, since it was not certain how many people would show up. It turns out that the conference covered those costs, but they were still personally responsible for the conference if they wanted to put it on again the next year, or the year after. Beman had the idea that there should be an independent legal entity for this, rather than two individual people. I forget the exact chronology, but pretty early on in the conference history, we ended up with The Boost Steering Committee, under the Software Freedom Conservancy (SFC). That is, we called it "The Boost Steering Committee", but there was no such legal entity. The legal entity that represented the BoostCon conference and Boost in general was SFC. In terms of legal entities, "The Boost Project", or "The Boost Steering Committee" was just a single division within SFC. This is something they reminded us of from time to time. At the time, Boost had no real expenses. The "wowbagger" server that we use to host the (now, legacy) website, and on which the releases are built, was hosted at Indiana University. The downloads of the build Boost releases were hosted at Sourceforge (I think; anyway, wherever it was, it was free). They later moved to other places, ending up finally at JFrog. They're no longer hosted for free -- see below. BoostCon made more money than it spent for a lot of years. It accumulated some reserves, and people would sometimes ruminate on what we might spend all that sweet, sweet cash on. No large expenditures were ever taken on though. The SFC started very small. We were project #3 I think (maybe #2? something like that). Over a few years, it took on more and more projects, until Boost was one of 20 or 25 SFC projects (again, I don't remember the exact numbers). SFC had a small staff then, and probably still does. As they grew, it became increasingly difficult to get anything done. They were overworked and understaffed, so this is not some failure on the part of the SFC so much as a logistical inevitability. One problem we had was getting them to pay vendors for services used by the conference. IOW, we would use some service, the vendor would send us a bill, and then we would send SFC like a thousand emails trying to get them to pay the bill. It was a nightmare to deal with. Jon Kalb, who was the conference chair at the time, asked the Steering Committee if we'd be open to breaking free of SFC, and forming our own non-profit organization -- a separate legal entity. Everyone agreed, Jon did a bunch of research and paperwork (thanks again, Jon!) and we formed a new 501(c)(3) US corporation called The Boost Foundation. This is why the Steering-Committee-under-SFC became the Boost Foundation Board. This is also why the name changed -- we needed a new name for the new legal entity. There was no secret agenda; there was no smoke-filled room. There was, however, pragmatism. Sometime around then -- once more, I don't remember the exact timeline -- we started losing all our free stuff. Someone at Indiana University realized that randos (that's us, Boost) were running a whole server in their lab, and asked us to remove it. So then we had to pay for hosting wowbagger. Some time later, the download hosts stopped giving away bandwidth for free as well. No problem, right? The conference makes money, Boost now needs money, so let's use the conference money for the Boost expenses that now have to be paid. (Note that this is something the SC/Board took on as it came up; it was not part of the original mission of the SC/Board, because there were no significant Boost infrastructure expenses previously.) The problem is that the conference makes less and less every year, due to a combination of changes in the way the venue charges (it all went up a lot), inflation, the expenses from the covid-cancelled year, etc. During all this, we kept things running as best we could. Eventually, the downloads became too expensive, and the C++ Alliance offered to pay for those. So now they do. The Foundation only pays for hosting wowbagger right now. Hopefully that sets the stage. To me, the important take-away is that the Foundation has tried to "keep the lights on" as I like to say, without bothering anyone on the list about it. The Board does more than just Boost infrastructure stuff, such as organizing the C++Now conference, and more recently, paying the hosting fees for the Beman Discourse server. Sorry this is so long. :) I may have some of these facts slightly wrong. Like, did BoostCon actually start in 2006? I couldn't figure out definitively which year it was, even though I was there. But I'm much more certain about the major events, and the reasons for things. I also left out most of the non-asset-stewardship aspects of the Steering Committee/Foundation, since they are mostly not germane to the current review. I nevertheless refer to one such aspect below. In light of the history above, here are some points I'd like to make regarding things I've seen said on this list about the Foundation: 1) The Board does not impose its will on the developers on this list. It does sometimes make recommendations or official "calls" of some kind, like saying we should use CMake. It doesn't actually have the ability, as the Boost Foundation Board, to enact such changes. This is not a matter of restraint. It simply can't make concrete changes; only the Boost developers can. Also, there never has been, and doesn't appear to me that there ever will be, any appetite for meddling in Boost development, or forcing developers to do things. 2) The Board is self-selected, in the sense that the Board nominates and votes on Board seats. Multiple Boost authors are on the Board: Peter Dimov, Glen Fernades, Jeff Garland, and me. There are others who are only there for the conference business. There are others, who joined more recently, interested only in Beman. 3) I've read on this list about the desire to "get back" to the Boost Steering Committee way of doing things. This does not make sense. There is no difference between the Boost Steering Committee and the Boost Foundation, except for the name. Sure, there is a change in membership over time. That would have happened with or without the name change. Perhaps this is a desire not to have the current Board membership? If so, please get involved. Asking a volunteer project to do things differently, without volunteering to help yourself, doesn't usually work out. Which brings me to: 4) The Board is a volunteer project, like Boost is. As such, people work mostly on what they care about, and don't really do much for things they don't care about. So when I read, "The Board is not communicating enough," I think there are a couple of things to consider. 4a) Do we expect volunteers to do the stuff they want to work on, and then communicate that they did that to someone else that was not working on that same thing? Do we do that with our Boost libraries? I might communicate changes, including bug fixes, in release notes. I do this because it affects others. But if I make a non-functional change, who do I tell, and why? Note that, when there has been a loss of service, someone has mentioned it on the list right away, as far as I know. Do we also want people to mention when the Board took some action that kept a loss of service from happening? Moreover, I'm not sure what transparency is lacking, given that: 4b) The board publishes minutes of every meeting, and you can come to the meetings if you're interested. Except for occasionally needing to handle a sensitive topic that we do not minute due to its sensitivity, these are not closed meetings. For example, our latest Board member was asked to join the Board because he kept showing up to these open meetings out of his own interest, and would take on tasks from time to time. As you all know, this is how pretty much all open source/volunteer projects work. In short, I think if a Boost user wants to know the details of how Boost works, they subscribe to the Boost mailing list. If a Boost developer wants to know the details of how the Boost Foundation works, they read the minutes and/or come to the meetings. Zach

5 6

Re: [boost] A history of the Boost Foundation
by Zach Laine 11 Sep '24

11 Sep '24

On Wed, Sep 11, 2024 at 2:41 PM Vladimir Prus <vladimir.prus(a)gmail.com> wrote: > > >> > > 1) The Board does not impose its will on the developers on this list. >> > > It does sometimes make recommendations or official "calls" of some >> > > kind, like saying we should use CMake >> > > >> > >> > So the email about cutting ties with the C++ Alliance, which started all >> > this, was just non-binding minority report? >> >> I don't get it. Isn't this the thing the developers are voting on >> right now? How is the Board imposing a change on the developers? > > > The original email had no proposal of a vote. Nor did it sound like a recommendation. Right. But again, where was the impact on the Boost developers? I, as a Boost developer was not expected to, nor asked to, do anything differently from what I had done before. This vote was all about the Board not wanting to deal with the Alliance. We think that there would be an adverse impact on the Bosot developers, and think, "screw the developers!" If we expected our decision to adversely affect Boost development, we would have made a different one. Zach

2 2

Boost Asset Stewardship Review from Matt
by Matt Borland 11 Sep '24

11 Sep '24

DISCLAIMER: I am a C++Alliance Employee Prior to my employment by the C++Alliance I had been a contributor to Boost for a few years primarily in the Math domain. I enjoyed working with everyone, so when an opportunity to join the C++Alliance came around I took it. I agree with the foundation that the core of Boost is volunteers, but by adding a number of part time and full time employees we are able to handle much larger projects and sustained maintenance that may just be otherwise unfeasible. I don't think, for example, GCC would be better off without RedHat employees working on it because many people depend on it just like many people depend on Boost. I like that the C++Alliance is heavily invested in the future of Boost and it's infrastructure. Drone is fast and has a diversity of architectures that aren't available in Github Actions. We've been adding CUDA support to Boost.Math and a testing environment for that was happily provided since there is a heavy demand signal from our users. The new website is a pretty clear improvement over the current one. We also have Sam Darwin who is already helping the distribution of Boost happen behind the scenes. I see no reason to not want to work with an organization that literally puts their money where their mouth is. The fiscal sponsorship model and the new steering committee are the right choice for the future. The fiscal sponsorship model is not new and worked for Boost in the past. The three (possibly five) members of the initial steering committee all have public and sustained interactions with the Boost community. I trust they have the best interests of the project in mind since they have skin in the game. I would like to echo what Chris said in his review. Tensions have obviously been high over the past weeks and months between some rather large personalities. Once this referendum is complete I hope that we can have a peaceful transfer of power and return to a more cordial environment with a focus on how we can make Boost better moving forward. Bottom Line: I vote ACCEPT for the C++Alliance's Fiscal Sponsorship Proposal Matt

2 1

[Asset Stewardship] A request for clarification
by Andrzej Krzemienski 10 Sep '24

10 Sep '24

Hi All, I have a couple of questions to the C++ Alliance representatives regarding the Fiscal Sponsorship Proposal. First, the proposal is very clear and informative. Thank you for this. I still have some questions, though. In Appendix 1: Paragraph 2.c says, "all community programs [...] shall be the ultimate responsibility of Alliance. What is meant by "community programs" here? Paragraph 3 says "should Alliance be required to pay any taxes [...]". What taxes do you mean here? Can you give an example? Paragraph 3 also uses the term, "Project agrees". Is this a mistake, or intentional? I understand that the Current Committee can agree to something. Or that the Steering Committee can agree to something. But how can the Project agree? Additional two questions. 1. When I am a maintainer of a library, what does it make me in the light of this agreement? Am I part of the Project? Or a donor to the Project? Or something else? 2. I have a problem internalizing who decides and signs-off on the complement of the Current Committee. Don't get me wrong. I personally support the proposed complement (including the proposed amendments); I just wonder how it works logically/legally. The Current Committee cannot appoint itself. The Alliance cannot arbitrarily say "you, you, and you". Is this Boost Asset Stewardship Review a vehicle for the legitimization of the Current Committee? Paragraph 8.d says, "If no Successor is found, Alliance may dispose of the Project assets and liabilities in any manner consistent with applicable tax and charitable trust laws." This sounds very harsh to me. If the Project faces the necessity to find another sponsor, and this fails, is the Alliance allowed to offer the domain name for sale, get rid of the mailing list archives, or offer the logo to someone else? Appendix 3 -- I do not see how it illustrates the boost.org Domain Registration Expiration Appendix 6 -- It is very nice promotional material. Thank you for doing this. But the term "the Official C++ Language Slack Workspace" draws my attention, and I have always wanted to ask this: what makes this slack workspace "official"? Neither Boost nor the C++ Alliance represents C++ or could make decisions or blessings in the name of C++. So, is it not a stretch? Regards, &rzej;

3 5