- Boost - lists.preview.boost.org

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

Re: [boost] Boost C++ in Australia
by Hans Dembinski 05 Apr '24

05 Apr '24

> [...] you're supposed to refer to these as "megameters" As an educated physicist, I concur (*). Also, it's time that the general public finally uses kilo-, mega-, and gigadollars, to avoid the confusion what a "billion" means in different languages https://en.wikipedia.org/wiki/Long_and_short_scales#Current_usage (*) Actually, not even physicists use megameters for some reason, neither does anyone say megagrams... people are so inconsistent.

3 2

Reminder: The master branch closes for the 1.85.0 release TOMORROW
by Marshall Clow 02 Apr '24

02 Apr '24

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

1 0

Re: [boost] Technical Excellence?
by Peter Dimov 02 Apr '24

02 Apr '24

Ivan Matek wrote: > If there is some boost contributing for dummies so that I don't waste more > time in PR review for maintainers than I saved for them by renaming 8 uses of > boost::array to std::array I would be happy to pick some tasks next weekend. Unfortunately the procedure for bringing a library up to date with C++11 is pretty convoluted in general; it's only easy if the library is actively maintained and has up to date CI, and even then, dependency changes require updating the CMakeLists.txt file. For an "old" library, what I generally do is 1. Update (or add) Github Actions CI 2. Fix any test failures that the above has exposed (this happens surprisingly often and is sometimes not easy) 3. If the library has C++11 dependencies and therefore already requires C++11, update meta/libraries.json with the 11 requirement and drop 03 from CI (if not, add a BOOST_PRAGMA_MESSAGE that C++03 will be dropped two releases from now) 4. Add CMake jobs to CI. This requires adding test/CMakeLists.txt and supporting files. 5. Finally, change boost::array to std::array and remove the include of <boost/array.hpp> 6. Regenerate CMakeLists.txt using `boostdep --cmake libname`, if it was generated, or update it manually, if not, to drop Boost::array 7. See if anything broke on CI, and fix it which... isn't generally something a new contributor can do on his own.

1 0

A few updates...
by David Sankel 02 Apr '24

02 Apr '24

Hi all, I have a few updates regarding Boost organization that I wanted to share with the wider community. First, as many of you are already aware, Vinnie Falco, Rene Rivera, and others from the C++ Alliance have set up a rival Boost website (boost.io vs. boost.org), Boost Twitter account (@BoostLibraries vs. @Boost_Libraries), and LinkedIn account. As this behavior is gravely injurious to the Boost community and amounts to a hostile takeover attempt, it has been decided to ban these individuals from the Boost mailing list for the foreseeable future. Libraries owned by these individuals will be removed from the main Boost distribution in future releases unless others volunteer to continue their maintenance. Additionally, we have initiated legal action to get these false Internet assets taken down under common trademark law. I hope with these steps we will finally put behind us the unfortunate events of the past few months. Second, we have decided to retire the Boost mailing list in favor of discord.boost.org to attract a newer demographic of Boost users and developers who prefer this medium to legacy mailing lists. The transition will not be immediate, but we hope to have it complete by April 1, 2025. I know some of you have been reluctant to this kind of change, but as Roy T Bennett once said, "change begins at the end of your comfort zone." Third, I am very pleased to announce that Microsoft has given the Boost Foundation a $850,000 grant as part of their Rust initiative. These funds will be used primarily to port Boost libraries to the Rust programming language. We will begin by porting recent additions to Boost, such as Boost.Parser, since some of the older libraries (e.g. Boost.SmartPtr) already have equivalents in the Rust standard library. The Boost community is invited to provide additional input as to the priority of various conversions. Finally, and with some regret, I must share the news that the Boost Foundation will be dissolving itself per popular request from Boost developers considering it (incorrectly) be concerned with only the C++Now conference. The Boost Foundation's assets will be held under trust by Robert Ramey and Niall Douglas until more appropriate governance is built. That's all for now. I hope y'all have a great week! -- David Sankel

7 7

[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