- Boost - lists.boost.org

[stacktrace] boost_stacktrace_from_exception on non-x86
by Tim Haines 24 Apr '24

24 Apr '24

This feature is guarded by BOOST_STACKTRACE_ALWAYS_STORE_IN_PADDING, but that is only enabled on x86 ( https://github.com/boostorg/stacktrace/blob/a33e198cf660c213e700d6f050a4641…) This means that ./bootstrap.sh --with-toolset=gcc --with-libraries=stacktrace ./b2 install threading=multi toolset=gcc always fails to build on non-x86 platforms. There are three current workarounds: 1) set boost.stacktrace.from_exception=off 2) set BOOST_STACKTRACE_LIBCXX_RUNTIME_MAY_CAUSE_MEMORY_LEAK 3) build with threading=single (1) prevents me from using this feature. (2) shouldn't be needed on it's face because I'm using gcc/libstdc++. (3) affects more than stacktrace. Is this an incidental error, or is there a reason I wasn't able to deduce as to why this feature can't be used on non-x86+libstdc++? It seems like the check for libc++ on non-x86 can't be entirely done at compile time. I definitely understand wanting to alert users to the dangers of using this feature, but there also doesn't seem to be a good way of detecting the presence of libc++ at compile time (hence the need for https://github.com/boostorg/stacktrace/blob/a33e198cf660c213e700d6f050a4641… ). Thanks. - Tim

1 0

Boost board update on website, twitter, etc.
by David Sankel 21 Apr '24

21 Apr '24

Hi all, We're overdue for a Boost website/Twitter status update as it relates to the board. In summary: - The board approved pointing boost.org to C++ Alliance servers running the new website once it's ready - The board is accepting a contribution from the C++ Alliance to upgrade the @Boost_Libraries Twitter account to premium, which simplifies delegation of credentials for posts - The C++ Alliance made their @BoostLibraries Twitter account private which means only its subscribers will see its posts. The website decision was made in the 3/28 board meeting which followed the 3/13 meeting where several on boost-dev were invited to the discussion. You can read the minutes here <https://docs.google.com/document/d/1zMKUX3nfdcOXT6nUIU4M_YRlCU4ywGoG40ouo3I…> . The website decision was not easy. There wasn't consensus in boost-dev nor on the board itself (it passed with 3 in favor, 2 against, and 1 abstention). However, a needed decision was made and I invite everyone to rally behind it and support its success. I want to thank Vinnie and those working for the C++ Alliance for their major Boost website contributions. I want to acknowledge the reviewers, active Boost authors, review managers, folks making releases, bug reporters, infrastructure maintainers, and the many others that contribute to Boost in various ways. These people constitute the Boost libraries project whose consensus is the primary means of community-wide decision making. The Boost Steering Committee (and now the Boost Foundation) was created by the Boost libraries project to make such decisions *only in the rare case of community deadlock*. While the Boost board is more than happy to provide feedback and financial support for Boost libraries initiatives, the board is taking its direction from the project and not the other way around. Thanks everyone for your passionate interest in Boost and I look forward to what comes next! David, Boost Foundation Chair

2 1

On Boost and modules: second part
by Ruben Perez 19 Apr '24

19 Apr '24

Hi all, Following the recent discussion on Boost and C++20 modules, I've been performing further investigations on the possible benefits and costs of offering module support in Boost. I've summarized my findings here: https://anarthal.github.io/cppblog/modules2 TL;DR: * While there isn't too much benefit for clean builds, incremental builds tend to be much faster with modules. * Right now, modularizing requires an effort for each modularized library. * Writing CMake files for module consumption won't be trivial. I'd like to know everyone's opinion on this: do you think these efforts would make sense? In the mid-term, this will require authors to review and merge module-related PRs, at the very least. I'm especially interested in hearing René and Peter's opinions, as maintainers of B2, Boost.CMake and many other core parts (as well as other authors'). If the community decides these efforts may be worthwhile, I volunteer to perform most of the required work. My first step would be to create a working prototype with a modularized Boost.Url (as a maintained, separately compiled library, with non-trivial dependencies), together with CMake tooling, to spot any pitfalls I've missed during my analysis. I'd also like to drag any present MSVC developers' attention on this bug which has nasty consequences on code like Asio: https://developercommunity.visualstudio.com/t/Using-%5f%5ftry-in-an-inline-… Thanks, Ruben.

4 4

[release] Boost 1.85.0 Release Candidate 3 is available
by Marshall Clow 18 Apr '24

18 Apr '24

The third release candidates for the 1.85.0 release are now available at: <https://boostorg.jfrog.io/artifactory/main/release/1.85.0/source/> The SHA256 checksums are as follows: e712fe7eb1b9ec37ac25102525412fb4d74e638996443944025791f48f29408a boost_1_85_0_rc3.zip 7009fe1faa1697476bdc7027703a2badb84e849b7b0baad5086b087b971f8617 boost_1_85_0_rc3.tar.bz2 16d16b9658753117c1434e5450c5eac194957f4b6d0b390b9d07900d37c115a4 boost_1_85_0_rc3.7z be0d91732d5b0cc6fbb275c7939974457e79b54d6f07ce2e3dfdd68bef883b0b boost_1_85_0_rc3.tar.gz The changes from RC1 are: * Boost.ASIO docs generate very long file names that are not usable on Windows. * Boost.Program options does not build in C++23 mode on clang truck (to be clang 19 before boost 1.86.0 is released) Note: It is possible that this is a bug in clang, and it’s in a clang that is not released yet. * Boost.Log has some broken links in its documentation. * A meaningless change to Boost.Array (add a space to a test file) Apparently the RC2 tarballs were mis-buiilt; some of them were missing the required changes. I believe that RC3 resolves that problem. 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

10 25

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

Things I Hate (Re: New Website)
by Vinnie Falco 17 Apr '24

17 Apr '24

Now that we're here I want to tell you about some things I hate. To clear out any suspense they are: 1. April Fool's 2. Deadlines 3. New Boost Website April Fool's I can't stand this fauxliday and I refuse to participate. Every year sees the C++ community produce an outsized load of lame jokes. The problem, I think, is that comedy on some level has to come at someone else's expense. Good comedy at least. Our community is so damn politically correct that folks are afraid to make a really good joke for fear of getting canceled at some level. Deadlines I hate deadlines. People ask me "how long will this take" and honestly I have no idea. About a decade ago I stopped trying to estimate how long things take as I never was able to give a reasonably accurate answer. I'm good at writing the code, but figuring out how long it will take - not so much. During development, unanticipated stuff comes up. A discovered design flaw or implementation obstacle, which can't be predicted. These days I just figure that if a project is properly staffed and there is reasonable daily progress, eventually it will get finished. New Boost Website Well I don't hate the whole thing but there is definitely stuff which is bothering me. Like how long the thing is taking. Seems like it is still not ready to go up on boost.org. But more importantly I have to be honest... I'm not feeling this Cairo font. I am just going to come out and say it: the old Quickbook stylesheets are superior to the new stylesheets which render in Cairo. Compare: https://www.boost.org/doc/libs/1_85_0/libs/beast/doc/html/beast/ref/boost__… vs. https://www.boost.io/doc/libs/1_84_0/libs/beast/doc/html/beast/ref/boost__b… or https://www.boost.org/doc/libs/1_85_0/libs/beast/doc/html/beast/concepts/Dy… vs. https://www.boost.io/doc/libs/1_84_0/libs/beast/doc/html/beast/concepts/Dyn… The new one is better than it was a month ago, thanks to Julio our new frontend developer. But it is still not as good as the old one. I cannot in good conscience propose replacing something old with something new unless the new thing is demonstrably superior. Or at the very least, equally as good. So I think we still have work to do. Thanks

4 7

[release] The master branch is now open for all changes
by Marshall Clow 16 Apr '24

16 Apr '24

Next deadline: June 26th - Boost 1.86.0 closed for new libraries and breaking changes` As always, the calendar is at: https://www.boost.org/development/ — Marshall

1 0

Boost.Graph security issues
by Jeremy Murphy 13 Apr '24

13 Apr '24

Dear Boost community, I've recently received a few security issue notifications from both the Google Chrome fuzzer project and Shielder (part of an OSTIF project), and basically I'm not sure how much to worry about them. I don't have time to fix them (but I can review and merge fixes), and I don't know how to draw attention to the need to fix them without publicizing the issues (which are still not published). It all depends on how many people actually are exposed via Boost.Graph and to what severity, right? I have no idea, but my gut tells me not many, as most Boost.Graph users I hear about are just using it internally, not exposing the interfaces to input from the Internet. But I'm not a security expert, that's why I'm asking you. What should I do? Thanks, cheers. Jeremy

3 5

Re: [boost] Boost C++ in Australia
by Jeremy Murphy 13 Apr '24

13 Apr '24

Hi David, Hello from Sydney, at least for the next six months. I'd love to catch up, although finding time is hard. Cheers. Jeremy On Wed, 3 Apr 2024, 8:05 am David Bellot via Boost, <boost(a)lists.boost.org> wrote: > Hi all, > > reading through the Boost mailing list, I've realized several of you live > in the country of kangaroos and cute koalas (and great white sharks and > funnel web spiders too, thinking of it). > > As I am too, why don't we find a good opportunity to gather, hoping that > we're in the same city. If it's not the case, then chances are we are > "just" a few thousands kilometers away from each other! > > Let me know what you think > > Cheers, > David > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost >

1 0

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