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

CMake Announcement from Boost Steering Committee
by Jon Kalb 13 Aug '24

13 Aug '24

The libraries produced by the Boost community have had a greater impact on the way that the C++ community writes code than any other library implementation. The focus of the Boost community will always be on the libraries, but it is undeniable that we are dependent on and often limited by the infrastructure of our trade. Years ago, the move to Git was contentious; yet, it was required to improve development. In a similar vein our build system has become an impediment for many developers and users, existing and prospective. Therefore, we, the Steering Committee, announce to the Boost community our desire and intent to move Boost’s build system to CMake for users and developers alike. We are soliciting comments and proposals from the community to guide the process and the goals. Our desire is that the community can come to consensus by the end of the calendar year with a vision of supporting users and developers. We understand that the actual process of achieving the end goal will be long, time consuming, and not without its share of conflict. We also recognize that the Boost community is comprised of bright and passionate individuals that are eager to get involved and help get work done. The members of the Steering Committee have been encouraged by the discussions and activity surrounding CMake on the mailing lists over the years and know that many people have voiced visions. We hope that each of you rejoins the discussion to support this initiative and contributes to the common goal of improving Boost’s integration into the broader C++ ecosystem. For the Boost Steering Committee, Jon Kalb, Chair jonkalb(a)boost.org

49 199

Boost Governance?
by René Ferdinand Rivera Morell 09 Aug '24

09 Aug '24

A disclaimer: I write this solely as a Boost Library author. And not in any other capacity or representing any other interest. It's now been at least a year since Boost switched from the Software Freedom Conservancy to the Boost Foundation for its governance organization. But have people noticed any difference? Did you know that switch happened? Did you know that they held an election for the Board of Directors and for the Officers? Do you know when that election happened? Do you know who got elected? Do you know how they were selected? Do you know what their responsibilities are? Do you know what their bylaws are? Do you know their financials? More importantly: Did you answer "no" to any of those questions? As a library author, I can say I definitely answered no to many of those questions. This is a problem. As authors, without asking, we should know those answers from the organization that governs our work. We should have input into how that organization governs. In other words, we deserve open and transparent governance; not the closed and opaque status quo. -- -- René Ferdinand Rivera Morell -- Don't Assume Anything -- No Supone Nada -- Robot Dreams - http://robot-dreams.net

10 9

Paul Bristow
by John Maddock 08 Aug '24

08 Aug '24

I've just heard that Paul Bristow who helped so much with the development of Boost.Math and indeed many other libraries, passed away peacefully last week. RIP Paul. Much missed. John.

6 5

boost::any_cast gives build errors with VS2022, boost v1.82 and C++17
by Bhuyan, Jyotideep 01 Jul '24

01 Jul '24

Hi, I was using VS2019, boost v1.78, and C++14 version and the below code was working well. Same code gives build error with VS2022, boost v1.82, and C++17 due to "o << *boost::any_cast<T>(&a); " Instruction. I wanted to know why it behaves differently. Code : class any_out { struct streamer { virtual void print(std::ostream& o, const boost::any& a) = 0; virtual streamer* clone() = 0; virtual ~streamer() {} }; public: any_out() : m_streamer(nullptr) { } ~any_out() { delete m_streamer; } template <typename T> any_out(const T& value) : m_streamer(new streamer_imp<T>), m_object(value) { } any_out(const any_out& a) : m_streamer(a.m_streamer ? a.m_streamer->clone() : nullptr), m_object(a.m_object) { } template <typename T> any_out& operator=(const T& r) { any_out(r).swap(*this); return *this; } any_out& operator=(const any_out& r) { any_out(r).swap(*this); return *this; } any_out& swap(any_out& r) noexcept { std::swap(m_streamer, r.m_streamer); std::swap(m_object, r.m_object); return *this; } friend std::ostream& operator<<(std::ostream& o, const any_out& a) { if(a.m_streamer) { a.m_streamer->print(o, a.m_object); } return o; } boost::any& get() { return m_object; } const boost::any get()const { return m_object; } bool empty() const { return m_object.empty(); } private: template <typename T> struct streamer_imp : public streamer { virtual void print(std::ostream& o, const boost::any& a) { try { if (a.empty()) { o << "<empty>"; } else { o << *boost::any_cast<T>(&a); } } } virtual streamer* clone() { return new streamer_imp<T>(); } }; // Members streamer* m_streamer; boost::any m_object; }; I have migrated to VS2022, boost v1.82, and C++17, and due to a build error, I have changed the code below. virtual void print(std::ostream& o, const boost::any& a) { try { if (a.empty()) { o << "<empty>"; } else { o << boost::any_cast<T*>(a); } } } any_out anyTest; anyTest = 100; std::string actualStr; actualStr = make_string() << anyTest; actualStr prints nullptr (0000000) instated of value 100 for VS2022, boost v1.82 and C++17 Best Regards, Jyotideep (JD) Please be advised that this email may contain confidential information. If you are not the intended recipient, please notify us by email by replying to the sender and delete this message. The sender disclaims that the content of this email constitutes an offer to enter into, or the acceptance of, any agreement; provided that the foregoing does not invalidate the binding effect of any digital or other electronic reproduction of a manual signature that is included in any attachment. Confidential - Company Proprietary

3 3

GSOC '24 at Boost
by David Bellot 05 May '24

05 May '24

Hi all, Another year, another GSOC's coming! As you all know now, Inbal is in charge of managing our GSOC program at Boost. Over the past years, I had the pleasure to work with many of you and we had the chance to have many great students and mentors. This year, however, it seems we don't have enough mentors yet. I know it's just the beginning of the year, but I would like to encourage you to join this program as a mentor, and help students to participate in Boost and become great C++ developers. It's a very rewarding journey I took myself years ago and you will learn so much, both on the technical and human side. If you want to become a mentor, just add your name to this shared spreadsheet: https://docs.google.com/spreadsheets/d/1_eUWRsXnhi_JwKZbHZsGQf3WNUESsAPE4lV… Cheers, David

4 3

A base64 library?
by Ruben Perez 17 Apr '24

17 Apr '24

Hi all, I've been thinking of writing a base64 encoder/decoder library for some time. I first found the need when writing ServerTech chat (https://github.com/anarthal/servertech-chat) and I couldn't find a library that suited my needs. All the libraries I could find were either forgotten one-day projects with no tests, or private parts of something bigger. >From this issue from Beast (https://github.com/boostorg/beast/issues/1710) it looks like this could be useful to people. My idea would be writing something that is: * Boost quality - extensive testing and fuzzing. * Configurable. My use case in ServerTech required me to not output padding chars, for instance. * Support for a streaming API. * Support for calling in a constexpr context. * I'd prefer to focus on doing base64 only and doing it well, rather than targeting arbitrary bases. I don't have any sample code yet. Following our recommendations, I'm only determining interest. My questions are: * Do you think a library like this could be useful to the C++ community? * If the answer to the above is yes, do you think it could belong to Boost, or would be better as a standalone library? Regards, Ruben.

13 30

Technical Excellence?
by Vinnie Falco 12 Apr '24

12 Apr '24

I guess I'm confused. My understanding is that libraries are considered good candidates for the Boost collection based on meeting some or all of certain criteria: * They offer useful, novel functionality not found elsewhere * The API is superior to other libraries that do similar things * The implementation is exceptionally performant * Solving a familiar problem in a particularly elegant fashion * The library is already popular and has field experience * The library offers C++ standard functionality for older compilers But some of the chatter on the mailing list suggests that the bar for a Boost library candidate is lower. That a library just needs to basically work, even if it duplicates functionality found elsewhere, or even if it does not have anything that one might hold up as an example of exceptional engineering. Boost libraries used to be cutting edge, to such an extent that they were adopted into the C++ Standard. And now the progress is in reverse. The Standard introduces a new component, and the Boost library follows (Boost.Charconv for example). In other cases I see libraries with few to no users limping into reviews, or absent discussions which question whether or not the bar for excellence is exceeded. When I used to participate in wg21 I complained about the "direct to standard" pipeline, where people would just write papers for the sake of it with no example code or real-world user experience. I have to wonder if we are not cultivating a "direct to Boost" pipeline by having relaxed or poorly-defined acceptance criteria. There are thousands of open-source libraries for doing things in a fashion that is "good enough." If libraries are not held to technical excellence and high standards during the review process then what is the value proposition of the collection? If libraries of average design and implementation are seen as passable for acceptance then how would this inspire any authors to strive for excellence? When I write a library there are always two factors in my mind: 1. that the use-case is compelling, and 2. that I can bring something to the table which demonstrates technical excellence. These are the libraries that I have contributed thus far and my process for designing them: 1. Boost.Beast This offers something never seen before which is a generic approach to HTTP and Websocket, based on Asio, which offers models and algorithms that are designed well (of course, it still has its flaws). The library already had many users ahead of the review, and was being used to transact economic value in a live product. I will note that my initial motivation for Beast was because the websocketpp library API was just terrible, and the alternatives even worse. 2. Boost.JSON When I needed JSON I looked at the alternatives and while RapidJSON was clearly the best in terms of performance I felt that it made several major design flaws in its API. Boost.JSON pretty much copies all of the good ideas from RapidJSON especially the performant implementation, and offers a redesigned API that follows C++ best practices with respect to copy and move, exceptions, and error codes. Furthermore I added the streaming parser and I introduced a novel means of managing memory resources which I believe corrects a design flaw in the standard. This library already had commercial users and lots of feedback before going into review. 3. Boost.URL Beast users regularly asked for URL parsing. There are some regex patterns floating around and some Spirit based parsers, and also some URL libraries that do the "five std::string data members" thing. I wanted something excellent, but the first two iterations of an API turned out to be crap and I gave up, as I do not like publishing mediocre libraries. Some time passed and with renewed energy I tried again and then I got it right. The URL is stored in its serialized form (just one string), allowing the possibility for having a url_view type in addition to the mutable container. I copied much of the API from a popular JS URL lib because, well hey why duplicate the effort if someone has already gone through the trouble :) Boost.URL offers particularly clean and robust interfaces for reading and modifying the values of each part of the URL both with and without the URL-encoding applied. The mechanism for lazily iterating the path and query sequences is novel. And it offers a strong invariant: the container will always contain a valid URL. The library further innovates by making public its parsing framework which is optimized for the type of grammars found in the Internet RFCs such as HTTP and the fields used in Websocket handshakes. Boost.URL had a bunch of users before the review was conducted. 4. Boost.StaticString This one is just a straightforward string container whose storage is fixed in capacity as a data member. Container libraries are often unexciting but they are necessary. StaticString follows all best practices for modern C++ containers. When I look at a proposed library I try to figure out what is great about it, how well it performs for its users (or even, does it have any users?), what part of the API is exceptionally well designed and ergonomic, but most importantly I want to ask: what makes this library stand out to the extent that it should be part of the library collection? What aspects of the library, if viewed by someone learning C++ or interested in improving their design skills, are inspirational? Is this overly demanding or exclusionary? Am I overthinking things? Should we be asking more of these types of questions and requiring better answers? What is the criteria for determining if a library is good enough to become part of the collection? Thanks

26 78

Fwd: A proposal for a modern build-system
by Daniele Lupo 11 Apr '24

11 Apr '24

On 23/03/2024 13:16, Hassan Sajjad wrote: > Hi. > > Could you please confirm if my proposal is under consideration? If so, > when can I expect an update regarding its status? > > Sorry for the delay, I had personal issues during those days. I've read the thread, and since now I can't see any serious issue or problem that make me think that the actual build system must be replaced. Maybe updated, but not replaced. For explaining more in detail my point of view (that, I will not ever repeat too many times, it's my personal one, so other people can have other ideas about it): - Boost does not pay people (as far as I know). You're asking for compensation in the first message, but nodoby will pay it, and nodoby asked for it. - I agree with others that three month of development are a bit too optimistic, and also in this case we must maintain two different build systems instead that one. - In the thread I've read many messages like "b2 can do this", "well, also hmake", but no messages like "hmake can do it and b2 it's not able to do it" "oh really? I'd love to have it!". I don't see any important use case that's requested by the community and that hmake will provide while b2 not. So the community wil use hmake to do the same things that at the moment it does with b2. - There's already another build system, even if not much official, and that's cmake. It works well and it's widely used, and that's supported by many package managers, like vcpkg. I have to say that hmake will not be used by them, so it will be limited to the scope of build boost like b2 actually does. Even in this case, it does not add anything. Basically, in the entire thread, in my opinion, there's not a single point that le me think that hmake will make the like easier to boost community. At most we'll have another tool that make the same things. And, repeating myself, I can see that new features actually not supported by b2, pratically modules, are easier to be implemented in b2 instead of using another build system and obligate the entire community to learn another tool for a feature that for now only a few of them will use. In addition to this, I strongly think that instead of a new build system I'll spend some effort, if necessary, in improving existing alternatives, like cmake, that are already widely used by the developer community around the world. Regards Daniele Lupo

4 6

Interest in a library for type-safe bitwise operations?
by tobi＠die-loews.de 06 Apr '24

06 Apr '24

Hi, I would like to gauge interest in a library that makes the usage of flag-like enumerations safer. The library is called Boost.Flags, and its key features are - provides type-safe bitwise operations for flag-like scoped / unscoped enumerations - turns undetected logical errors into type errors Further characteristics are - non-intrusive - only a function overload or a template specialization required to opt-in - single header-file library - no dependencies (only standard-library includes) - everything is constexpr - zero-overhead in optimized builds - requires at least C++11, uses newer features if available From the Boost.Flags documentation: > Why do we use the bits of integer types for Boolean options? > > - easy to define, e.g. as macros, integer constants or enumerators > - language support for setting and querying through bitwise operators > - compact representation in memory > - simple bulk transfer in interfaces (on many platforms an int can > hold up to 32 different Boolean options) > - enforces the usage of names, especially to prevent bool parameters > in interfaces: > - "Boolean arguments loudly declare that the function does more than > one thing. They are confusing and should be eliminated." [C. Martin, > Clean Code] But C++ already has everything to work with integer-based flags, so why do we need Boost.Flags? The answer is type-safety! With integer-based flags we can do too much. E.g. when there are multiple different integer-based flag sets, nothing prevents the programmer from accidentally mixing flags from unrelated flag-sets. And of course, there are problems with the bitwise negation operator~. If you want to know, what possibly could go wrong, read the docs. The Github page: https://github.com/tobias-loew/flags The online docs: https://tobias-loew.github.io/flags Example on Godbolt: https://godbolt.org/z/qbojncnd7 I am looking forward to your comments! Tobias

5 11

[release] Master branch is now open for bug fixes
by Marshall Clow 01 Apr '24

01 Apr '24

The master branch is now open for bug fixes, test and documentation changes. Other changes by release manager permission, as described in https://github.com/boostorg/wiki/wiki/Releases%3A-Beta-Merge-Policy The next deadline: On April 3rd, master closes for all changes. As always, the calendar is at https://www.boost.org/development/ — Marshall

12 22

boost.sqlite seeking endorsement
by Klemens Morgenstern 30 Mar '24

30 Mar '24

A while back I asked about interest in a boost.sqlite library and got enough engagement that I think it's worth proposing. Hence I am seeking an endorsement and would like to see if someone wants to volunteer as review manager. Code: https://github.com/klemens-morgenstern/sqlite Docs: https://klemens.dev/sqlite/

14 28

Slow mail archive and link?
by René Ferdinand Rivera Morell 27 Mar '24

27 Mar '24

I've known this for a long time, but only now decided to bring it up.. The mailman archive is both laggy and unhelpful. There's a significant lag between one sending an email to the list and it being reflected in the archive (https://lists.boost.org/Archives/boost/) I think it took 5 minutes with my latest message. I've noticed that for other mailman web archive lists I subscribe to, like the wg21 lists, there is no significant lag. And they even put a link to the archive for the specific message in the footer of the message immediately. First.. Can the lag be improved? Second.. Can a link to the archive message be included in the message? -- -- René Ferdinand Rivera Morell -- Don't Assume Anything -- No Supone Nada -- Robot Dreams - http://robot-dreams.net

4 5

[Parser] Review Results and Report
by Marshall Clow 27 Mar '24

27 Mar '24

The review of Zach's parser library ran from Feburary 19 -> 28th. If I have mischaracerized/incorrectly stated anyone's position, please let me know in this thread. REVIEW RESULT ----------------------------- The result is Boost.Parser is * ACCEPTED WITH CONDITIONS * into Boost. The following tickets in the parser repo should be addressed before adding this library to boost: Consider changing the way semantic actions are invoked https://github.com/tzlaine/parser/issues/106 Turn on -Wall for GCC and Clang builds https://github.com/tzlaine/parser/issues/107 Clearly indicate which directives create a new parser when used, which do not, and why it matters. https://github.com/tzlaine/parser/issues/161 Enable code coverage on Github project https://github.com/tzlaine/parser/issues/146 Add more examples and use cases to The Parse Context https://github.com/tzlaine/parser/issues/145 ABI-tag __has_include-guarded differing code https://github.com/tzlaine/parser/issues/151 API reference for char_ should explicitly state that it can be used without args https://github.com/tzlaine/parser/issues/150 Add no_case support to symbol tables https://github.com/tzlaine/parser/issues/149 REVIEW REPORT ----------------------------- We recieved 10 reviews during the review period, and two more after the review ended. Six reviews recommended ACCEPT One review recommended ACCEPT WITH CONDITIONS Three reviews reccommended REJECT One review did not reccommend an action. One review was of the documentation only. Thanks to everyone who participated. Thanks to Zach for writing the library, and participating heavily in the review. REVIEW COMMENTS ----------------------------- Several of the reviews sparked discussions, and many of the issues raised were debated back and forth on the mailing list. There was a lot of discussion about the use of Boost.Hana in the library; Zach defended it on the grounds that Hana's tuple has an `operator[]`, which is much more readable than using `std::get`. There was push back from the reviewers on this, not wanting to add a dependency (and learning curve) for yet another library. Currently, this is selectable at compile time; Zach said that he would consider defaulting to use std::tuple instead of Hana::tuple. Phil had trouble with a custom parser that used the double parser; I believe that this was resolved, and this is now captured as a test case: https://github.com/tzlaine/parser/blob/boost_review_changes/test/parse_coor… There was a long discussion about semantic actions, and how they are defined/invoked. https://github.com/tzlaine/parser/issues/106 was created to address this. Several people mentioned compiler error messages one such example is https://github.com/tzlaine/parser/issues/105 and compiler warnings https://github.com/tzlaine/parser/issues/107 Christian thinks that the examples comparing Parser to Spirit3 should emphasize the advantages of Parser. Zach to update the examples. He also asked for general design guidance on writing rules vs. actions. https://github.com/tzlaine/parser/issues/161 Matt (and others) asked for more CI coverage; Zach said that he welcomed help setting it up. https://github.com/tzlaine/parser/issues/146 Alan requested that the numeric parsers use Boost.Charconv for the conversions. He also stated that the section in the docs "The Parse context" is confusing https://github.com/tzlaine/parser/issues/145 David noted some ODR issues https://github.com/tzlaine/parser/issues/151 and he also noted that the docs for the char parser don't say it can be used without arguments: https://github.com/tzlaine/parser/issues/150 He also mentioned that he would really rather see a library design more like Text.Parsec from Haskell. Дмитрий wanted to know why the symbols didn't support 'nocase'. https://github.com/tzlaine/parser/issues/149 He also thought that the attribute for parsers with semantic actions is none is not advertised well enough https://github.com/tzlaine/parser/issues/148 Mohammed asked a question about parsing chunk-encoded HTML bodies efficiently. Zach replied that this wasn't supported directly, but you could write a custom parser to do it. Christian reported a hideous performance overhead when parsing JSON. (100x slower than Boost.JSON) Zach and Peter investigated, and it turned out that the construction of a stringstream for tracing was much of it, and the rest was also part of the tracing mechanism. Zach reworked the tracing code, and now non-debug builds are much faster. https://github.com/tzlaine/parser/issues/152 REVIEW ACKNOWLEDGMENTS ----------------------------- Thanks again to Zach for Boost.Parser Many thanks to our expert reviewers, commenters and watchers. Your contributions keep Boost excellent! Marshall Clow Boost.Parser Review Manager

13 22

Pre-C++14 compilers
by Дмитрий Архипов 26 Mar '24

26 Mar '24

Recently we stopped supporting C++03. Now, the only compilers which support C++11, but do not claim some support of C++14 (that I am aware of) are GCC versions 4.8 and 4.9. But even C++11 support in those GCC versions is fairly buggy and those who still test on them often have to resort to various tricks to make their code build. Those compilers are fairly old, and the systems that use them increasingly go extinct. This makes me consider removing them from CI. Which is why I want to ask the community several questions: 1) Do you still use GCC 4.8 or 4.9? 2) If you do, is there a specific date when you plan to drop them? 2) Do you use some other compiler which supports C++11, but not C++14 (even with flags like -std=c++1y)?

10 12

Re: [boost] [release] Master branch is now open for bug fixes
by Christophe Henry 25 Mar '24

25 Mar '24

Hi Marshall, I would like to merge in MSM this bugfix (2 missing includes): compile break in 1.85.0.beta1 when using favor_compile_time · Issue #70 · boostorg/msm (github.com) <https://github.com/boostorg/msm/issues/70> and this doc fix: Boost 1.85.0: Backend Dokumentation · Issue #69 · boostorg/msm (github.com) <https://github.com/boostorg/msm/issues/69> PR: Feature/1.85 beta by henry-ch · Pull Request #71 · boostorg/msm (github.com) <https://github.com/boostorg/msm/pull/71> Develop builds and tests ok. Regards, Christophe

2 1

A proposal for a modern build-system
by Hassan Sajjad 25 Mar '24

25 Mar '24

Hi. Preface: C++20 modules and header-units are a great addition to C++. There are numerous benefits of these. One of them is a faster compilation. Conventional build-systems however are unable to benefit from C++20 modules or header-units. Boost current build-system b2 does not support C++20 modules or header-units. CMake does not support C++20 header-units https://gitlab.kitware.com/cmake/cmake/-/issues/25293. I developed the build-system HMake https://github.com/HassanSajjad-302/HMake. It is in C++ and MIT Licenced. It supports drop-in header-files to header-units replacement. While compilers support processing a header-file as header-unit, no other build-system supports this feature. With this I compiled SFML with C++20 header-units https://www.reddit.com/r/cpp/comments/1555g6b/hmake_build_system_02_compili…. In the post, I mentioned that 2-3.5x speed-up was achieved but I did some more testing recently and an even better speed-up of 2.7-4.7x was achieved i.e., the speed of header-units is further improving with recent iterations. Proposal: I want to propose my build-system HMake for boost. Besides its already state-of-the-art C++20 modules and header-units support, it will be the first to support https://lists.isocpp.org/sg15/2023/11/2106.php or https://lists.isocpp.org/sg15/2023/11/2146.php if any of this gets implemented. These papers present ideas for faster module adoption and avoiding redundant module compilations. These need support from build-system. This way boost could be a breeding ground for C++20 modules adoption. Also, I have good experience with boost's current build-system b2 as a good portion of HMake's current API is inspired by it. Timeframe: I will complete this proposal in 3 months. Deliverables: 1) 2-months: Boost basic configuration compiled with C++20 header-units. This is more of a lone sprint. 2) 3-months: All boost current configurations + new with header-units and modules + tests and examples. This will require more active involvement by the current maintainers. I will give weekly updates here and will make a video after 2 months presenting the progress made. This will be to help other contributors so they can ensure that their library is fully supported. Cost: Standard C++ Developer Compensation for 3 months (Negotiable). Payments are to be issued monthly. But you can back out at any point in case you are unsatisfied with development speed or direction. Impact: While I don't see any reason for it to be a flop, it is an engineering endeavor so there is some inherent risk. The best-case scenario is that it improves Boost usability and 2.5x compilation speed improvement starts a domino effect for HMake and C++20 header-units and modules adoption. Best, Hassan Sajjad

9 37

Boost::serialize: im doing an Windows MSVC to Linux GCC port and i have a linker error (with a small example)
by Dennis Luehring 25 Mar '24

25 Mar '24

im doing an Linux/GCC port of an huge ~1Mio LOC/15 years grown Windows/MSVC project - my first step was switching over to CMake replacing the Studio-Solution file and in around 2.5 weeks i went from a hell lot of compile errors down to full compilation and nearly full linking - happy state so far :) but i stumbled over an linking problem using Boost::serialize with template types (in static libs and hundreds of them in this project) the code compiles and links with MSVC but not with GCC/Clang ld/lld/mold under Linux tested with Boost 1.84.0 - needs Boost::serialization ---- /usr/lib64/gcc/x86_64-suse-linux/13/../../../../x86_64-suse-linux/bin/ld: CMakeFiles/linux_link_error_test.dir/main.cpp.o: in function `boost::archive::detail::iserializer<boost::archive::text_iarchive, MyType<double, 2ul> >::version() const': main.cpp:(.text._ZNK5boost7archive6detail11iserializerINS0_13text_iarchiveE6MyTypeIdLm2EEE7versionEv[_ZNK5boost7archive6detail11iserializerINS0_13text_iarchiveE6MyTypeIdLm2EEE7versionEv]+0x15): undefined reference to `boost::serialization::version<MyType<double, 2ul> >::value' ---- nm -C shows that the symbol 'boost::serialization::version<MyType<double, 2ul> >::value' is 'U' undefined in the the lib but i don't understand why the linker is looking for this header-only version function - and what MSVC is doing different to accept it as is i reduced the big scenario down to a more or less trivial sample to show the effect loading a dummy type "MyType" it compiles and links with MSVC but GCC gives me the linker error https://github.com/LowLevelMahn/linux_link_error | | build.txt | CMakeLists.txt | +---linux_link_error_lib <-- a static lib with the serializable 'MyType' | CMakeLists.txt | MyType.hpp <-- definition of the dummy type | serialize_MyType.hpp <-- definition of the boost serialization routines | test.cpp <-- dummy code for the static lib | \--linux_link_error_test <-- console app using MyType serialization CMakeLists.txt main.cpp the structure of the sample project, static-library, using different headers for type-definition and its serialize routines is intentionaly like in the original project - so i can maybe easily adapt a solution to my real project, i hope the sample is bare enough :) how to build: mkdir linux_link_error_dev cd linux_link_error_dev git clone https://github.com/LowLevelMahn/linux_link_error.git mkdir _build cd _build # Windows/MSVC cmake -G "Visual Studio 17 2022" -A x64 -DCMAKE_PREFIX_PATH=[boost-path]\lib\cmake ..\linux_link_error # Linux/gcc cmake -DCMAKE_PREFIX_PATH=[boost-path]/lib/cmake ../linux_link_error #or without prefix path if boost is installed as package in your distro cmake ../linux_link_error cmake --build . result: builds on windows on linux with gcc i get the linker error from above my system: recent Tumbleweed SUSE gcc 13.2.1 clang 18.1.1 ld: 2.42.0 lld: 18.1.1 mold: 2.30.0 my boost build: wget https://boostorg.jfrog.io/artifactory/main/release/1.84.0/source/boost_1_84… tar -xf boost_1_84_0.tar.bz2 cd boost_1_84_0 ./bootstrap.sh --prefix=/home/testing/boost_1_84_0_install ./b2 install it could be that all the MSVC magic/micro compiler/linker differences i've learned in the last years don't let me see the truth :(

1 1

Boost BCP tool is abandoned.
by René Ferdinand Rivera Morell 24 Mar '24

24 Mar '24

While making changes to update the various tools I found that the BCP tool is abandoned. As in it hasn't been updated for a couple of years. And because of changes to Boost.Filsystem no longer builds. And since no one has complained about it not building, I'm guessing no one uses it. There's two choices to deal with this: 1. Find someone to maintain it. 2. Delete it and move on with other more important things. I favor #2. -- -- René Ferdinand Rivera Morell -- Don't Assume Anything -- No Supone Nada -- Robot Dreams - http://robot-dreams.net

4 3

Linker errors under Linux on using locale in a tiny example - using my own boost build
by Dennis Luehring 21 Mar '24

21 Mar '24

i can't built a simple locale from_utf using example with my own build boost 1.84.0 [system] SUSE Tumbleweed gcc (SUSE Linux) 13.2.1 20240206 [revision 67ac78caf31f7cb3202177e6428a46d829b70f23] [boost build] using https://boostorg.jfrog.io/artifactory/main/release/1.84.0/source/boost_1_84… tar -xf boost_1_84_0.tar.bz2 cd boost_1_84_0 ./bootstrap.sh --prefix=/home/test/boost_1_84_0_install ./b2 install ---- [CMakeLists.txt] cmake_minimum_required (VERSION 3.14) project (MyTest) set(CMAKE_CXX_STANDARD 17) set(CMAKE_CXX_STANDARD_REQUIRED ON) list(APPEND CMAKE_PREFIX_PATH "/home/test/boost_1_84_0_install/lib/cmake") find_package( Boost REQUIRED COMPONENTS locale ) add_executable( my_test main.cpp) target_link_libraries( my_test PRIVATE Boost::boost ) ---- [main.cpp] #include <boost/locale.hpp> int main() { auto x = boost::locale::conv::from_utf( "blun", "ISO-8859-1" ); return 0; } ---- build: _build>cmake ../MyTest _build>make [ 50%] Building CXX object CMakeFiles/my_test.dir/main.cpp.o [100%] Linking CXX executable my_test /usr/lib64/gcc/x86_64-suse-linux/13/../../../../x86_64-suse-linux/bin/ld: CMakeFiles/my_test.dir/main.cpp.o: in function `std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > boost::locale::conv::from_utf<char>(char const*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, boost::locale::conv::method_type)': main.cpp:(.text._ZN5boost6locale4conv8from_utfIcEENSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEPKT_RKS8_NS1_11method_typeE[_ZN5boost6locale4conv8from_utfIcEENSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEPKT_RKS8_NS1_11method_typeE]+0x42): undefined reference to `std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > boost::locale::conv::from_utf<char>(char const*, char const*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, boost::locale::conv::method_type)' collect2: error: ld returned 1 exit status make[2]: *** [CMakeFiles/my_test.dir/build.make:97: my_test] Error 1 make[1]: *** [CMakeFiles/Makefile2:83: CMakeFiles/my_test.dir/all] Error 2 make: *** [Makefile:91: all] Error 2 any idea what is happening here?

3 4

Porting to Openvms
by Barrett Southworth 18 Mar '24

18 Mar '24

I see the source files for setting up config.hpp. But I don't see how to create source files for OpenVMS (the vms.hpp is really out of date). The compiler VSI CXX. Or any of the other options. Is there a guide for setting up the config that I'm missing? If not any suggestions for how to go about setting up those files?

2 2

release clang++ std=c++23/26 trunk version emit diagnostics errors on #include <boost/program_options.hpp>
by Bjørn Roald 17 Mar '24

17 Mar '24

https://gcc.godbolt.org/z/d3PTjdMhr this is fixed by changing suspect throw() declarations with BOOST_NOEXCEPT I have not checked rest of boost for diagnostics with this compiler, but my understanding is that throw() declarations are no longer part of the standard and compilers may emit diagnostics like this. Is there any reason, except for the work to be done, not to use BOOST_NOEXCEPT everywhere? — Bjørn

2 1

Social Media Guidelines
by Vinnie Falco 16 Mar '24

16 Mar '24

I guess I'll take a stab at offering a starting point for social media posting guidelines. When I had access to post to the Boost_Libraries account there were basically two kinds of posts. Official communications from the Developers, and unofficial but relevant announcements. The Developers are defined as the set of members of the boostorg GitHub organization who have the Owner role, plus any proxies they authorize. Official communications include: * When a review starts https://twitter.com/Boost_Libraries/status/1622664075217092609 * When review results are available https://twitter.com/Boost_Libraries/status/1768833941341896756 * When a Boost release is published (usually 3 a year): https://twitter.com/Boost_Libraries/status/1735542393229967849 * When a change in policy for the libraries happens: https://twitter.com/Boost_Libraries/status/1633484289693339648 Official communications are identifiable by the Boost logo watermark appearing at a prescribed location and size in the color Boost Mustard. Examples of unrelated but relevant announcements include: https://twitter.com/Boost_Libraries/status/1716891934986530946 https://twitter.com/Boost_Libraries/status/1748504615371334006 Unofficial posts should have images if possible, but never with a Boost logo watermark, to denote that the post does not presume to speak for or have an association with the Developers. Anyway, these are the set of rules I informally invented when I had posting privileges to Boost_Libraries. I always checked with other developers before posting anything, especially for unofficial posts to ensure that the content was relevant to Boost in some fashion. This could be used as the starting point for explaining the guidelines for operating official Boost accounts. There is a page in the new site docs (a work in progress for sure) which is intended to capture these guidelines in a way that is easily understood by readers: https://www.boost.io/doc/contributor-guide/tweeting.html Disclaimer: That page is probably not be up to date, and is not the product of a consensus-driven process. But it can be, someone just needs to volunteer to do the work. Thanks

1 0

Review schedule update
by Mateusz Loskot 16 Mar '24

16 Mar '24

Folks, I have just updated the review schedule with status of the reviewed libraries as well as Boost versions releasing the new libraries. I'll appreciate if authors of the libraries (from STLInterfaces onwards) could verify if I've got their release version right. p.s. thanks to Christopher Kormanyos for nudging me about the update. Best regards, -- Mateusz Łoskot - on behalf of the Review Wizards Team

2 3

Re: [boost] (Important) Boost Foundation meeting this Wednesday
by Louis Tatta 16 Mar '24

16 Mar '24

On Mon, Mar 11, 2024 at 12:23 PM David Sankel <camior(a)gmail.com> wrote: > Our monthly Boost Foundation meeting is this Wednesday at 3pm Eastern > (12pm Pacific). > To: Boost developer community and Boost Foundation Board Hi everyone, I write to address two important matters regarding recent events. First, upon reviewing my messages with David and conferring with Vinnie, I must apologize for a miscommunication. I did not realize that “copyright assignment” was a term of art which means to transfer all legal rights and title. I thought instead it meant that Boost Foundation would receive a license to reproduce the logo without permission in referential contexts. Vinnie wasn’t involved in this so it is unfair to blame him; in fact, the task of this communication was delegated to me specifically because David suggested that dealing with someone else might be preferable to dealing with Vinnie. Second, as the agenda for the Boost Foundation board meeting occurring on March 13th includes a discussion of the new website, I would reiterate our proposed contribution to the developer community. A transfer of copyrights is not in line with Boost tradition, but it is still possible for us to have a healthy relationship. Thusly we repeat our previous offer: 1. The boost.org domain will point to The C++ Alliance servers running the new website, which we will operate and pay for. 2. Administrative access to the new cloud services will include Sam Darwin (CTO of C++ Alliance), plus anyone appointed by the developer community. 3. The new Boost logo (“B Mark”) will have its copyright and trademark retained by The C++ Alliance, and it will be published under a license which allows for irrevocable, permissionless reproduction in the context of referring to the Boost Libraries. The text for this is being prepared by our legal team, and it will be similar to the wording found under “Foundation name and C++ logo” here https://isocpp.org/home/terms-of-use. 4. Work on the website and documentation will continue in the repositories now under control of the developer community at https://github.com/boostorg/website-v2 and https://github.com/boostorg/website-v2-docs and licensed under the BSL. 5. If and when the developer community feels that the new website, infrastructure, or level of support received does not meet with expectations, the boost.org domain can be pointed away from The C++ Alliance servers. We believe this proposal is fair, generous, and respectful to tradition. It honors contributors by empowering them to continue their work, in a way that preserves the independence of the Boost project. Thank you for your consideration in this matter. Louis Tatta CEO, The C++ Alliance, Inc.

8 17

Suspicious changes to Serialization
by Peter Dimov 14 Mar '24

14 Mar '24

The current Serialization emits the following warning: c:\projects\boost-root\boost\serialization\extended_type_info_typeid.hpp(118) : warning C4700: uninitialized local variable 'ap' used which looks legitimate and is caused by the removal of `va_start(ap, count);` in this commit https://github.com/boostorg/serialization/commit/2805bc3faa8f8fb7ce80ec5181… This looks like a mistake to me, and is probably going to cause problems.

3 3

[release] Boost 1.85.0 beta 1 is available
by Marshall Clow 14 Mar '24

14 Mar '24

Boost release 1.85.0 beta 1 is now available at: https://boostorg.jfrog.io/artifactory/main/beta/1.85.0.beta1/source/ The SHA256 checksums are: c13b76f420684a8d5b2eb0f297c281348ba0311d50354d952c5ce7c689e7879b boost_1_85_0_b1.zip e65d529023c7b08d0b92c53fff24ce9df9568cc0fe667c90caf8a9dbc5e63b0d boost_1_85_0_b1.7z 9c1ce4793342e8e57eb34c61f774a9dac0c6fc036084785e416613a18091bacc boost_1_85_0_b1.tar.gz cf7449faedeac9b76bade8ee59007cc4456a14de375dfcbd9e6e38aabe8a1334 boost_1_85_0_b1.tar.bz2 There was one problem reported during the beta release process; when you build the release using b2, it will emit a warning: [errno 2] failed to scan file '': No such file or directory This is harmless, and will be fixed for the final release. the release notes are available at: https://www.boost.org/users/history/version_1_85_0.html Please try the beta and report any problems you encounter. Thanks to everyone who contributed to the release. -- Boost Release Team

3 4

Github releases for CI
by Peter Dimov 14 Mar '24

14 Mar '24

In addition to the CMake releases on Github, I've modified the action to also create releases for use with b2 (with the headers copied to boost/ and removed from libs/*/include, but without the documentation.) These would be useful for CI, which would hopefully lower the pressure on the official downloads. E.g. https://github.com/boostorg/boost/releases/tag/boost-1.85.0.beta1

1 0

[release] Boost 1.85.0 Release Candidate 1 is available.
by Marshall Clow 12 Mar '24

12 Mar '24

Available at: <https://boostorg.jfrog.io/artifactory/main/beta/1.85.0.beta1/source/> The SHA256 checksums are as follows: fa31215de3a4d2d010c0bc6e42cc63da76be82899f145ea6a6034b5bf3e6e297 boost_1_85_0_b1_rc1.zip 3b16d693acd4ee1745b0d9267555f7e34387527a02817f0c81bf8ec963b7c569 boost_1_85_0_b1_rc1.tar.bz2 20c7d2ccbbddeb56e618aa80960ea4dd38cbc4912b9a05fefef31c290519154e boost_1_85_0_b1_rc1.7z 7a28cd03e8e48b59a898900c953a9194b8f1efbb8c6149703b7faf08642c0cf7 boost_1_85_0_b1_rc1.tar.gz As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. -- The Release Managers

8 17

Reminder: Review for Zach's parsing library starts on Feb 19th
by Marshall Clow 11 Mar '24

11 Mar '24

That’s a week from now. Github: https://github.com/tzlaine/parser Docs: https://tzlaine.github.io/parser — Marshall

14 54

[release] Request to merge B2
by René Ferdinand Rivera Morell 11 Mar '24

11 Mar '24

Can I merge the latest, 5.1.0 (a), release of B2 to master at the next opportunity? By next opportunity I mean whenever the release managers think it's appropriate. :-) [a] Release notes: <https://github.com/bfgroup/b2/releases/tag/5.1.0> -- -- René Ferdinand Rivera Morell -- Don't Assume Anything -- No Supone Nada -- Robot Dreams - http://robot-dreams.net

2 1

New Website: State of the review / pending issues
by Ion Gaztañaga 07 Mar '24

07 Mar '24

Hi to all, We've had quite an intense debate regarding the proposed new website. I've tried to extract the main technical comments expressed in the ML to to determine the current state, fix any misunderstanding and try to establish a constructive thread: ------------------------- ------------------------- 1) Repository: the website code was hosted in cppalliance's github. It was transferred to boostorg. I understand this as an improvement as it's in the same level as other boost libraries. 2) License: Before transferring it to boostorg, a request to change the license to BSL was made. The license change was announced on February 21, and boost.io says it's BSL, so I guess it's solved now. Source files in the repo (https://github.com/boostorg/website-v2) have no copyright notice, I don't think it's something that is required, but usually all Boost source files have the notice and point to the license. I'm not a lawyer, but if the site is open source, anyone can fork and improve it, and ownership and copyright of the source code follows the standard Boost practices (BSL). Anyone with enough technical expertise can put up a server with the original or forked code and re-run the site in case of cpp.al goes away or if there are disagreements. 3) Privacy Policy: There was a comment about information from third parties and the use of Google Analytics, location data... AFAIK there is a new privacy policy page (https://www.boost.io/privacy/) which does not mention any location data and says a notification will be sent to registered users on any change. There is a issue to implement account deletion (https://github.com/boostorg/website-v2/issues/965) opened by Vinnie, so it should be implemented soon. 4) Terms of use: It was suggested that there needed to be a page like "Terms of Use" composed with help of a lawyer. AFAIK there is a new page (https://www.boost.io/terms-of-use/) that is much simpler and easier to read than the original. I'm not sure if Andrey's comments are addressed with the new TOU. Andrey, it's ok now? 5) GDPR: A issue was filed (https://github.com/boostorg/website-v2/issues/960) and there was a discussion in the ML about not having any analytics tool to avoid cookie banners or a couple of analytic tools that were compliant with GDPR. The github issue was resolved stating that: - Google Analytics was removed and Plausible was deployed (e.g. no cookies. IP addresses are anonymized with a hash function and rotating salt value), - YouTube Embed on the homepage was changed to an external link to the video. I understand that with those changes the site is GDPR-compliant. Is that right? 6) Moderation: We had a discussion about how moderation should be performed in the site (mainly as an anti-spam mechanism) and how it's implemented now in the mailing list (volunteers). My understanding is that the new website has some moderation tools so that anyone can submit news, etc... and that the same ML method (volunteers blessed in the ML) should be used to appoint the moderators for the site (not necessarily the same people that moderate the ML). ------------------------- ------------------------- I don't know if this summary is accurate, the aim was synthesize several ML threads into a single post, certainly I could be wrong on several points, please correct me in that case. Now the next question is: *What's missing technically so that the new website can to live?* If technically we have an agreement or we are near that, then we can: - Know if there are non-technical aspects that need to be ironed out. - Know if there is any alternative to be discussed and compared with the proposed website. If so, let's put it on the table, review and compare it. - Schedule a plan so that Boost can have a new modern website soon. Does this make sense? Best, Ion

8 10

[release] The Master branch is now CLOSED for the 1.85.0 beta.
by Marshall Clow 07 Mar '24

07 Mar '24

Please do not commit anything to ‘master’. — Marshall

1 0

Boost.Parser review result delayed
by Marshall Clow 06 Mar '24

06 Mar '24

I had to go out of town for a couple of days, and appear to have brought hone a cold. Sorry for the delay. — Marshall

2 1

[release] Master Branch closes for the release TOMORROW
by Marshall Clow 06 Mar '24

06 Mar '24

As always, the calendar is here: https://www.boost.org/development/ — Marshall

1 0

Boost.Parser Question about digit separator support
by Olaf Peter 04 Mar '24

04 Mar '24

Hi all, In the past I had some attempts with Spirit.x3. C++, VHDL and other languages support literal digit separators. On Stackoverflow.com there are some workarounds (in the context of VHDL's digit separator '_' ) for X3, which works but are unattractive and to unwieldy/unflexible. Is there a native/direct support for it at Boost.Parser? Thanks, Olaf

2 1

Reminder: Master branch closes for the 1.85.0 beta release on WEDNESDAY
by Marshall Clow 03 Mar '24

03 Mar '24

Calendar is here: https://www.boost.org/development/ — Marshall

1 0

Re: [boost] Reminder: Review for Zach's parsing library starts on Feb 19th
by Peter Dimov 02 Mar '24

02 Mar '24

Zach Laine wrote: > On Fri, Mar 1, 2024 at 2:15 AM Peter Dimov <pdimov(a)gmail.com> wrote: > > > > Zach Laine wrote: > > > > > I'm not sure what the tests reported earlier were doing, but I > > > > > definitely don't see orders of magnitude difference. > > > > > > > > I used this file: > > > > > > > > https://github.com/boostorg/json/blob/develop/bench/data/twitter.j > > > > son > > > > > > Using that file, I get similar results to what I already posted (the > > > numbers are different, but the ratios between them are the same). > > > > > > I managed to make a change that was much smaller -- no template > > > parameter required. I consistenty see 1.5x slowdown for Parser vs. > > > Boost.JSON for files around this size, and 2x or so for much larger > > > files (~25MB). > > > > That's probably because you are measuring I/O in addition to parsing. > > > > https://github.com/cmazakas/parser-review/blob/main/test/json.cpp > > > > only measures the parsing part. > > Quite right! After building it locally, I do see an advantage to the template > parameter approach -- that is, controlling the contents of scoped_trace_t with > an NTTP that is true/false when trace is enabled/disabled. scoped_trace_t is > specialized to be empty when the NTTP is false. I'll be committing the template > param-based approach soon. > > For those keeping track, with Christian's test framework, I get 35X worse > performance of the JSON parser example vs. Boost.JSON. This seems like a > reasonable factor to me. I wrote that example in a single, and made no > attempt to optimize it in any way; it is an example. Boost.JSON is a dedicated > JSON parser emphasizing efficiency. There's probably some room for Boost.Parser automatically applying certain optimizations to "naively" written parsers. For example, a lot of the time here is spent in skipping whitespace, using this rule: auto const ws_def = '\x09'_l | '\x0a' | '\x0d' | '\x20'; This generates an or_parser that contains four separate omit_parsers, each with a char_ inside. If I change it by hand to auto const ws_def = bp::omit[ bp::char_( "\x09\x0a\x0d\x20" ) ]; which I assume is equivalent, time improves from 365ms to 316ms (*). And that's still far from optimal, because (1) skipping whitespace can in principle be done with the equivalent of `find_first_not_of` and (2) the characters are a runtime value in the above, but something like `cxchar<'\0x09', '\0x0a', '\0x0d', '\x20'>` could be even faster. It should be possible for the library to automatically turn the "naive" ws_def into something more optimal, and then special-case `skip` for this common case. In the general case this is complicated by the existence of attributes and semantic actions; transforming parsers should take care to preserve those. But in this specific case none are present. (*) Under clang-cl. GCC -O3 has different views of the world and times there are 165ms and 181ms, respectively.

1 0

Late review of Boost.Parser
by David Sankel 02 Mar '24

02 Mar '24

# Are you knowledgeable about the problem domain? Yes. I've written several parser combinator libraries in C++ and used still more in C++ (Spirit v1, v2, and qi) and other programming langauges (Haskell's Parsec, attoparsec, and others). # How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? I read through the tutorial documentation and some of the reference documentation. I also tried to create several examples with the library and made comparisons to Haskell's Parsec. # What is your evaluation of the potential usefulness of the library? Very # What is your evaluation of the documentation? The documentation isn't great. Consider char_ <https://tzlaine.github.io/parser/doc/html/boost/parser/char_.html>'s documentation. It includes no examples and fails to mention it can be used without arguments. It seems strange that the tutorial focuses so much on semantic actions. It seems like the more common case would be to parse into some kind of abstract syntax tree. # What is your evaluation of the design? Much of the wealth of research into parser combinators wasn't incorporated into this library. I didn't see in the documentation, for example, an easy way to "map" one parser's attribute into another. This kind of thing should be a basis operation provided by the library. # What is your evaluation of the implementation? The usage of has_include is a ODR nightmare for large codebases. It would be better to generate some kind of config.hpp that sets these definitions at compile time. For custom variant/tuple types, user specialization of variable templates is also an ODR nightmare. Again, a config.hpp would be better for this. For this, though, I don't think the configurability is worth the complexity. We have standard types for these so we should use them. # Did you try to use the library? With what compiler? Did you have any problems? Yes, I tried to use the library with a modern compiler on a MacOS machine. I didn't have any problems building. # Do you think the library should be accepted as a Boost library? No, I do not think it should be accepted. Overall, I think the syntax has too much focus on magically filling in user-provided structures instead of the basics of monadic parser combinators and basis operations. Consider the following Haskell parser which evaluates simple parenthesized sum expressions. I wasn't able to use Boost.Parser to accomplish this after reading the documentation and several attempts. I'm sure it's possible, but I don't see how it can be done using the combiners and primitives provided. import Text.Parsec.String (Parser)import Text.Parsec integer :: Parser Integerinteger = do n <- many1 digit return (read n) integerPlus :: Parser IntegerintegerPlus = do x <- integer y <- (try $ char '+' >> expression) <|> return 0 return $ x+y parentheses :: Parser Integerparentheses = do char '(' x <- expression char ')' return x expression :: Parser Integerexpression = integerPlus <|> parentheses

5 9

Boost Tools
by Robert Ramey 01 Mar '24

01 Mar '24

For some time I've felt that our Boost tooling could be improved. By boost tooling I mean things like b2, boost unit testing and integration testing, documentation generation, reports like dependencies, website, etc. Currently we rely on certain privileged authors to develop these things then then upload them to the boost directories. This has worked, but it could be better. We spend what seems to me an inordinate amount of time chasing down anomalies, researching errors, responding for requests for help, etc. I think design, robustness, documentation could be improved. I think that the the most natural way for us to do that would be to adopt the practices that we have used successfully for decades to develop superior quality libraries to the design and development of tooling. That is: a) Someone proposes a new tool or improvement in an existing one on this list. His proposal includes a working though likely incomplete prototype, documentation, tests, demo etc. b) This is subjected to the same formal review process that libraries are. c) Subject to this review, the proposal is either rejected, accepted or accepted with conditions. Of course this would only apply to new tools and updates of existing ones. Robert Ramey

1 0

The Review for Zach's parser library has concluded
by Marshall Clow 01 Mar '24

01 Mar '24

Thanks to everyone who participated, and especially to those to submitted reviews. (And Zach, of courser) I’ll have results soon. — Marshall

1 0

Boost.Parser parsing length-prefixed strings efficiently
by Mohammad Nejati [ashtum] 01 Mar '24

01 Mar '24

Hi everyone, I have two questions about the following code, which attempts to parse length-prefixed strings using the proposed Boost.Parser: ``` std::string input = "[5]HELLO[5]WORLD"; unsigned int size = 0; auto action = [&size](auto & ctx) { size = bp::_attr(ctx); }; auto lps_parser = '[' >> bp::uint_[action] >> ']' >> bp::repeat(std::ref(size))[bp::char_]; auto result = bp::parse(input, *lps_parser); ``` 1. Is it possible to eliminate the need for the action and size variable by using some kind of placeholder in bp::repeat that utilizes the attribute of the first parser? 2. How can we make this part of the parser more efficient: bp::repeat(std::ref(size))[bp::char_] The current implementation seems to loop and execute bp::char_ parser on each character, while all it needs to do is chunk a portion of the input string. Regards, Mohammad Nejati

2 1