Date view Thread view Subject view Author view

From: Arnaud Becheler (arnaud.becheler_at_[hidden])
Date: 2025-05-29 16:00:02

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_may_13/
- 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
Date view Thread view Subject view Author view