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

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