- Boost - lists.boost.org

[bloom] Post-review changes
by Joaquin M López Muñoz 25 Jun '25

25 Jun '25

Hi, For those interested, I've just merged a branch incorporating most of the feedback received during the review of Boost.Bloom. Arnauld Becheler has once again been tremendously helpful with the process. More details here: https://github.com/boostorg/bloom/pull/32 https://github.com/boostorg/bloom/issues?q=is%3Aissue%20state%3Aclosed%20au… Revised documentation here: https://32.bloom.prtest3.cppalliance.org/libs/bloom/doc/html/index.html Boost.Bloom will be released with Boost 1.89. Thanks to all the people who have contributed to its improvement! Joaquin M Lopez Munoz PS. List of changes: * removed superfluous inline (Alexander Grund) * made hasher equivalence a precondition for &=/|= (Andrzej Krzemienski) * documented exception safety guarantees (Andrzej Krzemienski) * mentioned Bloom filters are called so after Burton H Bloom (Dmitry Arkhipov) * added warning about OOM for very small FPR (Ivan Matek) * stressed config chart x axis is capacity/num elements rather than plain capacity (Ivan Matek) * s/[SIMD] is available/is enabled at compile time (Ivan Matek) * shut down clang-tidy warnings (Ivan Matek) * used "set union" for more clarity (Andrzej Krzemienski) * stressed early on that boost::bloom::filter is _not_ a container (Claudio DeSouza) * added bulk operations to roadmap (Dmitry Arkhipov) * added try_insert to roadmap (Konstantin Savvidy) * added estimated_size to roadmap (Konstantin Savvidy) * added alternative filters to roadmap (Konstantin Savvidy) * used <cstdint> instead of <boost/cstdint.hpp> (Rubén Pérez) * mentioned endianness when serializing filters (Rubén Pérez) * corrected sloppiness about optimum k determination (Tomer Vromen) * added run-time specification of k to roadmap (Tomer Vromen) * added test/CMakeLists.txt (Rubén Pérez) * added CMake-based testing to GHA (Rubén Pérez) (#8) * added <boost/bloom.hpp> (Rubén Pérez) * added Codecov reporting (Rubén Pérez) (#9) * moved from boost::unordered::hash_is_avalanching to ContainerHash's boost::hash_is_avalanching (Ivan Matek/Peter Dimov) * added syntax highlighting to code snippets (Rubén Pérez) * avoided C-style casts in examples (Rubén Pérez) * added acknowledgements section (Peter Turcan) * added Getting Started section (Peter Turcan) * fixed example Jamfile and added example building to CI (Rubén Pérez) (#10) * added diagram about overlapping vs. non-overlapping subarrays (Rubén Pérez/Ivan Matek/Vinnie Falco) * made first code snippet self-contained (Rubén Pérez/Peter Turcan) * added more comments to genome.cpp (Rubén Pérez) * added support for arrays as blocks (Tomer Vromen) (#24) * removed emplace (Seth Heeren/Peter Dimov) (#25) * required the allocator to be of unsigned char (Seth Heeren/Peter Dimov) (#26) * added compile-time validation of Block types (Rubén Pérez) (#27) * added value type to displayed filter names in tables (Tomer Vromen) (#28) * used -march=native rather than -mavx2 (Ivan Matek) * adopted hash strategy with fastrange plus a separate MCG (Kostas Savvidis/Peter Dimov) (#30) * made doc improvements (Peter Turcan/Arnaud Becheler) (#29) * several maintenance commits

2 2

Is it possible to use SVN for develop library, which may be applyed by Boost?
by Leonid . 24 Jun '25

24 Jun '25

4 4

[DynamicBitset] Write access to the repository
by Gennaro Prota 20 Jun '25

20 Jun '25

Hi everyone, I'd like to do some maintenance work on my library, DynamicBitset. Could you please give me write access to the repository? Thanks. -- Gennaro Prota <https://prota.dev>

3 6

[bloom] Benchmarks with Knuth multiplier-based hash production
by Joaquin M López Muñoz 17 Jun '25

17 Jun '25

Hi, As per feedback given here: https://lists.boost.org/Archives/boost//2025/05/259548.php I've experimented with the hash production scheme suggested by Kostas, where h_{i+1} is calculated as h_i * 6364136223846793005 mod 2^64: https://github.com/joaquintides/bloom/blob/refs/heads/feature/alternative-h… These benchmarks show the performance of each filter configuration with the original mechanism and, on the next row, the new mechanism (filter names marked with *): https://github.com/joaquintides/boost_bloom_benchmarks/blob/alternative-has… I can't draw any definitive conclusion as to whether the new mechanism affects performance, probably because the GHA-run benchmarks have a good deal of noise and variations in CPU speed. Maybe a keener eye than mine can tell, or if you're interested in trying the benchmark locally please tell me so and I can instruct you on how to do it. Feedback welcome, Joaquin M Lopez Munoz

4 21

mailman upgrade
by Sam Darwin 17 Jun '25

17 Jun '25

Hi, As discussed earlier, mailman2 is end-of-life and no longer supported. We are planning to upgrade the mailing lists from mailman2 to mailman3. This will be done in-place, importing the previous archives and user list into a mm3 instance hosted at the same URL lists.boost.org. An example staging instance can be viewed at https://lists.preview.boost.org Mailman3 is more complex than Mailman2 with multiple components including "web" and "core". After the upgrade your account should still exist in the core backend, which means you will continue to receive messages and be able to send emails. However, to interact with the web frontend (optional) you must register an account using the same email address at https://lists.boost.org. Registering in the web portal will require setting up a new password, and confirming the email address. Be sure to use your existing email from before. Any previous passwords will not be valid. If you don't create an account in the web UI, your email subscriptions to the lists continue. But you can't yet log in to configure the account. No action is needed right now. Wait until after the upgrade. All previous messages will be imported to the new system. Additionally, the earlier archives in the form of static plain html pages will be available at https://listarchives.boost.org/ The imported lists are Boost, Boost Announce, and Boost Users. Activity on any other lists is remarkably low such as 1-2 emails per year. Please migrate other discussions to Github Issues, Slack, or one of the main mailing lists. Let us know any concerns. Report issues in the github repository cppalliance/boost-mailman. The tentative schedule is Tuesday June 17. Plan on not using the list for one day, or perhaps a few days. Roll back to mailman2 if something unusual is discovered soon after going live. Chat out-of-band in cpplang slack boost channel.

8 19

[fsc] Boost presence in WG21 meeting at Sofia, Bulgaria
by Joaquin M López Muñoz 16 Jun '25

16 Jun '25

Hi everyone, We have brought some Boost advertising material to the ongoing WG21 meeting at Sofia, Bulgaria, and several Boost people are also participating there. Let me share a poster of Boost.Hash2 introduced by one of its authors, and long-time Boost contributor, Peter Dimov. Using a link to the X post so as to not burden the mailing list with a large image: https://x.com/Boost_Libraries/status/1934649592403939668 We'll be posting some other pics of the meeting during the week. Hope you like it! Joaquin M Lopez Munoz Boost Fiscal Sponsorship Committee

1 0

[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 10 Jun '25

10 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