- Boost - lists.boost.org

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

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