December 2024 - Boost - lists.preview.boost.org

Pretty printer module
by Дмитрий Архипов 14 Apr '25

14 Apr '25

Recently Niall Douglas posted about his idea to embed GDB pretty printers into binaries using a header. At the time I was thinking about a good way to deploy pretty printers for JSON that facilitates their autoloading. After Niall's post I experimented a little bit more, and I came to the conclusion that indeed nothing beats embedding via a C++ header in terms of convenience. At the same time I was also thinking about testing that pretty printers do in fact work. Given that pretty printers (usually) are implemented as a Python module, it initially looked like one could just run a Python program and import GDB Python modules. But actually you cannot. It turns out, though, you can run a Python script with GDB as the interpreter. After several iterations I arrived at this setup: https://github.com/boostorg/json/blob/develop/test/printers.cpp. A script converts this file into a Python script that uses GDB to break on certain lines and check if a particular expression produces a particular output when printed. While doing all this I thought that most of this work can be useful to other libraries. So, I moved the reusable parts into a separate directory (https://github.com/boostorg/json/tree/develop/pretty_printers) and added both a b2 module, and a CMake module. For B2. Importing: https://github.com/boostorg/json/blob/develop/build.jam#L8-L9 https://github.com/boostorg/json/blob/develop/build/Jamfile#L13 (Re)generating the header: https://github.com/boostorg/json/blob/develop/build/Jamfile#L88-L95 Testing: https://github.com/boostorg/json/blob/develop/test/Jamfile#L96-L101 For CMake: Importing: https://github.com/boostorg/json/blob/develop/CMakeLists.txt#L54-L55 (Re)generating the header: https://github.com/boostorg/json/blob/develop/CMakeLists.txt#L56-L63 Testing: https://github.com/boostorg/json/blob/develop/test/CMakeLists.txt#L80-L88 My questions to the community: do you find this useful? Would you use it in your Boost or non-Boost library? If you do, the module should be moved to tools rather than stay in libs/json.

12 24

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

11 Feb '25

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

5 9

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

04 Feb '25

Dear All, Surprise! The Boost formal review of the Boost SQLITE library starts *TODAY*, taking place from November 13th, 2024 to November 22nd, 2024 (inclusive). I apologise profusely for springing this on you without prior warning. The error is entirely mine. I am extending the period by one day to compensate. The library is authored by Klemens Morgenstern (@klemens-morgenstern in the CppLang slack). Documentation: https://klemens.dev/sqlite/ <https://anarthal.github.io/mysql/index.html> Source: https://github.com/klemens-morgenstern/sqlite <https://github.com/anarthal/mysql/> >From the documentation: boost.sqlite is a simple to use C++ sqlite library. It provides a modern interface using facilities like error_code, views (e.g. for blobs) and the ability to use boost.describe or boost.pfr for parameterised queries. Supported features include: - typed queries - prepared statements - json support - custom functions (scalar, aggregate, windows) - event hooks - virtual tables SQLite provides an excellent C-API, so this library does not attempt to hide, but to augment it. Please provide in your review information you think is valuable to explain your choice to ACCEPT or REJECT including SQLITE as a Boost library. Please be explicit about your decision (ACCEPT or REJECT). Some other questions you might want to consider answering: - Will the library bring additional out-of-the-box utility to Boost? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - Will the choice of API abstraction model ease the development of software that must talk to a SQLITE database? - Are there any immediate improvements that could be made after acceptance, if acceptance should happen? - Did you try to use the library? With which compiler(s)? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? More information about the Boost Formal Review Process can be found at: http://www.boost.org/community/reviews.html The review is open to anyone who is prepared to put in the work of evaluating and reviewing the library. Prior experience in contributing to Boost reviews is not a requirement. Thank you for your efforts in the Boost community. They are very much appreciated. Richard Hodges - review manager of the proposed Boost.SQLITE library Klemens is often available on CppLang Slack and of course by email should you require any clarification not covered by the documentation, as am I.

17 61

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

29 Jan '25

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

15 85

GSoC 2025 Projects
by Matt Borland 24 Jan '25

24 Jan '25

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

5 8

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

28 Dec '24

Hi everybody, I presume somebody thought of this before but for some reason it never happened, but just in case it was never discussed I wonder if people here believe adding an nicer version of find(with different name obviously) to associative containers in boost would be beneficial? Since boost::optional allows references this would work. I presume naming is what most people will have strong feeling about. I personally prefer ofind/oat since I love short names, Barry suggested different names in his blog <https://brevzin.github.io/c++/2023/05/23/map-api/>, e.g. try_at. boost::optional did not get all the updates C++23 std::optional got, e.g. transform that make this usage compose nicely, but those could be added to boost::optional.

13 80

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

23 Dec '24

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

14 75

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

21 Dec '24

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

3 2

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

20 Dec '24

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

2 1

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

19 Dec '24

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

1 0