May 2025 - 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