- Boost - lists.boost.org

[atomic] RFC: Bitwise operations for enums
by Andrey Semashev 15 Jun '25

15 Jun '25

Hi, There were quite a few times when I wanted to use bitwise operations on atomic<enum>, where the enum lists a number of flags that could be combined with bitwise AND, OR and XOR. Neither std::atomic nor Boost.Atomic enables bitwise operations for enums, so I had to resort to workarounds, such as using atomic<underlying_type_t<enum>> with explicit casts to and from the underlying type of the enum. Obviously, this is rather tedious, and I would prefer not to have to do this. I'm not sure what was the original rationale for not allowing bitwise operations for std::atomic<enum>, but I would guess these points were a part of it: 1. Not all enums represent bit masks, so for some enums the bitwise operations wouldn't make sense. 2. There may be user-defined bitwise operators defined for an enum, and presumably atomic<enum> would not invoke them to implement atomic bitwise operations. (Because it is generally not possible to make an arbitrary user's operator implementation atomic, other than to wrap it in a CAS loop, which defeats the point of having a dedicated atomic operation.) Some users may find this surprising. 3. For some operations, there may be multiple reasonable implementations. For example, bitwise complement (operator~) may be inverting all bits in the enum representation or only those bits, for which there are named values. An atomic<enum> could possibly implement the former, but the user's operator~ could implement the latter, which would introduce a discrepancy in behavior. Also, ironically, if atomic<enum> attempted to solve the problem #1 by detecting presence of user-defined bitwise operators for the enum and took it as a sign that the enum is a bit mask, this would only emphasize the problems #2 and #3. So, clearly, on one hand the functionality could be useful in practice, and on the other hand there may be pitfalls and confusion coming from it. I wonder what people think about this. Would you prefer to have the support and deal with the consequences or the status quo? Perhaps, you had your own solutions to this problem? Maybe there are other strong reasons to not have it? Personally, I'm leaning towards having the functionality rather than not. You can always not use what you don't want or need, but not the other way around. Thanks.

4 12

Modular build progress.
by René Ferdinand Rivera Morell 09 Jun '25

09 Jun '25

It's been some time since the last update on B2 modular build support.. so here it is. Having accumulated more than 170 PRs to make the minimal needed changes to the libraries we are now down to only 13 needing, and ready, to be merged (https://github.com/users/grafikrobot/projects/1/views/2) And except for the MultiPrecision PR for John Maddock, the other 12 are in the hands of the Boost owners to merge. In other words.. We are almost done. I'm crossing fingers that this can get done before the next Boost release! -- -- René Ferdinand Rivera Morell -- Don't Assume Anything -- No Supongas Nada -- Robot Dreams - http://robot-dreams.net

1 0

[bloom] Request for feedback: support for extended block types
by Joaquin M López Muñoz 06 Jun '25

06 Jun '25

Hi, In the Boost.Bloom review, Tomer Vromen asked for support for extended Block types ranging over more space than a simple integral type --in particular, he was interested in the case where the block occupies 64 bytes. I've added support for this at https://github.com/joaquintides/bloom/tree/feature/array-block With this extension one can write, for instance, filter<int, 1, block<std::uint64_t[8], K>> where the block is an array of 8 uint64_t's --> 64 bytes. The performance for this extended block types can be consulted at https://github.com/joaquintides/boost_bloom_benchmarks/blob/array-block/REA… (look at the last row of each table). As expected, the performance is better than the equivalent classical bloom filter for the same or similar K (first entry of each table), and the FPR is worse (higher). My question is: considering the performance achieved, is this extended block type case worth supporting? Thank you, Joaquin M Lopez Munoz

1 0

[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.

1 0

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