- Boost - lists.preview.boost.org

Boost Asset Stewardship Review - Some questions received
by Glen Fernandes 10 Sep '24

10 Sep '24

The following questions were sent to me about the assets that the C++ Alliance already manages. My replies are included: 1. What are these alternate domains, and how do they differ from boost.io ? These are domains that the C++ Alliance provided for us when we had that issue where boost.org was down for a long period of time. At the time I wasn't sure we would even get boost.org back or what the timeline for recovery would be. I thought that we should provide a backup domain that users can be directed to until the issue is resolved. The C++ Alliance offered to help and registered boostlibraries.org and boostcpp.org that point to our website hosting. boost.io is the domain for people to preview the new website that the C++ Alliance built, developed by Fastly with content contributions from Boost users and developers. 2. Why do we need to pay to support downloads if the hosting is free? The storage costs are minimal but the bandwidth is not. At one point Boost downloads approached 60TB per month and Bintray couldn't afford to support us for free. JFrog generously offered to take over. Recently, our downloads started approaching almost 200TB per month, and now even JFrog couldn't afford to keep hosting us for free. They suggested we use a CDN to reduce traffic costs. I reached out to multiple providers to get a good deal. The best rate was from Fastly but this was also too expensive. The C++ Alliance offered to handle these costs and we subscribed to Fastly. Sam Darwin administers our Fastly account. For the list discussion, you can start at: https://lists.boost.org/Archives/boost/2024/01/255654.php Glen

4 4

Re: [boost] Replacing the ML with a forum
by Andrzej Krzemienski 09 Sep '24

09 Sep '24

śr., 26 kwi 2023 o 16:08 Vinnie Falco via Boost <boost(a)lists.boost.org> napisał(a): > Before we replace the mailing list with a forum (and implement a mail > gateway) can I get feedback on how you use the mailing list from your > email client? > Every message comes as a separate email to me. > > Are you using a threaded e-mail reader? Gmail groups all the emails from the topic as an email thread. > If so, do you care if > discussions are changed to be flat (like Discourse)? What does "flat" mean here? I am not familiar with Discourse. Could we get a sample or example? Regards, &rzej; What is important > to you (besides that you can continue to use your email client)? > > Thanks > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost >

5 7

Boost Asset Stewardship Review from Jakob
by Jakob Lövhall 09 Sep '24

09 Sep '24

I’m not affiliated with either the C++ Alliance or the Boost Foundation. I’m merely a boost user and sends occasional patches as contribution. The regulatory parts of the proposals are naturally US specific, and I want to make it clear that I do not understand the nuances of those parts. This is my short review. Boost Foundation: The bullet points and values stated in the proposal from the Boost Foundation seems strange to me and does not align with what I have been able to discern from public discourse. I haven't seen the transparency that’s being discussed. Engagement to provide said transparency seems lacking from the Boost Foundation. The emphasis on inclusivity over merit feels like a pathway to decline, as it explicitly excludes other groups beyond the intended inclusivity targets. This seems harmful to Boost and its community and should be avoided. The Boost foundation highlights code of conduct (and policing the discussion) as important going forward. I think it can be damaging, and should thus be avoided. Additionally, the Boost Foundation has not adequately addressed the infrastructure needs of Boost. In contrast, the C++ Alliance has stepped in to handle these concerns. C++ Alliance: Vinnie and others from the C++ Alliance have been actively engaging with the community on Slack and the mailing list—my two main points of contact. This provides transparency, builds relationships, and fosters discussions around technical issues, all of which are beneficial. The C++ Alliance has provided much-needed infrastructure assistance, particularly in cases where the Boost Foundation has failed to address long-standing issues (e.g., wowbagger). They support the maintenance (and at times creation) of libraries which I find useful. They promote on twitter, which I like, I've found good tools and libraries from twitter before and I expect others to also do so. having Boost on twitter therefore helps reaching those who might not have thought about boost when thinking about how to solve their current (C++) problems. The C++ Alliance focuses on merit over identity, which I believe is the right approach. Conclusion: I vote to ACCEPT C++ alliance proposal.

2 1

Regression Test Crashing
by Tom Kent 09 Sep '24

09 Sep '24

All- I've been pretty busy lately so just noticed this, but as of August 18 *all* the regression runs have broken during execution. The tail of the results log shows: - cxx11_char16_t : yes [47] - cxx11_char32_t : yes [47] - windows-sdk-supports-bcrypt : no [14] - windows-sdk-supports-bcrypt : no [51] error: Unable to find file or target named error: '/mnt/fs1/teeks99-06/run/boost_root/libs/charconv/build//stage' error: referred to from project at error: '../tools/check_build/test' Similar on windows: - cxx11_char32_t : yes [62] - windows-sdk-supports-bcrypt : yes [21] error: Unable to find file or target named error: '/C:/teeks99-09/run/boost_root/libs/charconv/build//stage' error: referred to from project at error: '../tools/check_build/test' Tom

4 8

Boost Asset Stewardship Review from Frank Wiles
by Glen Fernandes 08 Sep '24

08 Sep '24

Frank contributed the following review below, sent to me directly. > Vote: Transfer Boost Assets to the C++ Alliance > > Association with library: Occasional user. Long time OSS contributor > in other areas. Was paid to help C++ Alliance build the new boost.io > > Rationale: > > While my association with Boost is not large, I have seen first hand > the care the C++ Alliance has taken to both "do the right thing" and > drive for consensus with the Boost community. > > As someone who has been deeply involved in other software nonprofits > (Django Software Foundation directly, Python Software Foundation > tangentially) this proposal is certainly well thought out and > detailed. Most importantly it covers "end state" cases in the event > the Steering Council or C++ Alliance want to change or end the > relationship in the coming years. > > It seems clear to me that the C++ Alliance is driving the majority of > air in terms of breathing new life into Boost and the assets can > safely be within their control, if for no other reason than to reduce > friction in continuing to push things forward. > > -- > Frank Wiles > President/Founder of REVSYS > www.revsys.com > @fwiles Frank, thank you again for the review. Glen

1 0

Boost Asset Stewardship Review from Ali Asadpoor
by Glen Fernandes 07 Sep '24

07 Sep '24

Ali, thank you for the review. Everyone, Ali contributed the following review to glenfe -at- boost.org reposted verbatim here: On Fri, Sep 6, 2024 at 8:49 PM Ali Asadpoor wrote: > > Dear Glen, > > Hear is my review of the proposal doc: > > *** > Currently I don't see a bright future for boost library. Soon STL > will offer networking and later it might offer alternatives to other > awesome libraries in the boost. Seems STL is slowly catching up with > boost and it's killing it. > I was happy to read that The C++ Alliance might provide boost with > a second chance to glow again. Boost needs more human power to > process input from community faster and I think The C++ Alliance can > improve this aspect. > *** > > Best regards > Ali

2 1

Re: [boost] Boost Asset Stewardship Review begins 09/03 (Updated)
by Glen Fernandes 07 Sep '24

07 Sep '24

On Fri, Sep 6, 2024 at 7:44 PM Ion Gaztañaga wrote: > A: Yes, I think C++ Alliance’s proposal should be accepted, with a few > suggestions: Ion, a great many thanks for your review and the sentiments expressed within. Everyone, Ion's review didn't make it to the developer list because of an error in the address. I will ask him to repost it when he can tomorrow morning. Glen

1 0

Asset Stewardship Review
by M P 07 Sep '24

07 Sep '24

Here is my review of the proposed Boost.AssetStewardsipReview ## What is your evaluation of the design? The C++ Alliance has laid out a solid plan for boosting Boost, covering everything from revamping the website to improving integration, documentation, and library support. They’ve clearly identified the main issues and have offered practical, detailed solutions. They’re big on involving the Boost community and stakeholders, encouraging feedback and participation, and valuing everyone’s input. The Alliance is upfront about potential challenges like delays and costs, but they address these issues realistically. They’re not just offering quick fixes but are investing in new tools and dedicated staff for long-term support. On the flip side, the Boost Foundation’s concerns about the Alliance’s transparency and use of paid contributions might come across as overly critical. Sticking to slow decision-making and rigid governance could be seen as a barrier to innovation. Their focus on a purely volunteer-based setup might limit growth, and their critique of gender representation doesn't offer clear solutions. Some of their proposals, like improving mailing list behavior and adopting new tools, are a bit vague and might not be enough to attract fresh contributors or more dynamic approaches. ## What is your evaluation of the implementation? The implementation outlined in the text is well-organized and covers all the essential bases for Boost's long-term success. The C++ Alliance has already proven its value by setting up crucial infrastructure, like continuous integration and IT support, and by contributing to various libraries. The new Boost website is fantastic! Its modern design and user-friendly layout make it easy to navigate and find what you're looking for. With its fresh look and improved functionality, it's sure to catch the eye of new users and make their first experience with Boost a great one. Whether you're a seasoned developer or just getting started, the site’s clean interface and accessible resources are a huge plus. Their plan to revamp Boost’s brand and enhance its visibility is forward-thinking and aligns with what the community needs. The proposal to have the Alliance take on fiscal sponsorship aims to streamline operations and ensure financial stability. One thing to keep in mind is that the Alliance proposal comes with a legal agreement where a Steering Committee, made up entirely of Boost authors, gets to make decisions about the shared resources. If they're not happy with how things are going, they have the power to move those resources elsewhere. This kind of setup isn't mentioned in the Foundation proposal. So, while the idea of the Alliance handling fiscal sponsorship could definitely streamline operations and boost financial stability, how it plays out will depend on how well the Alliance and Boost community work together. ## What is your evaluation of the documentation? The C++ Alliance proposal is easy to follow and straightforward, clearly showcasing its contributions to Boost and laying out plans for future growth. It does a great job of explaining the benefits of the proposed governance changes and shows a real commitment to being open, sustainable, and collaborative. ## How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? I have dedicated considerable time to studying the proposals and related documents, and I have been aware of the ongoing conflict for some time. ## Are you knowledgeable about the problem domain? To some extent. With Boost's popularity declining in recent years, it's at a critical crossroads, and its future success may very well hinge on this decision. ## Do you think the C++ Alliance proposal should be accepted? Yes Miguel Portilla

2 1

Asset Stewardship Review
by Christian Mazakas 06 Sep '24

06 Sep '24

Disclaimer: Alliance employee Hi, I'm a little confused at what the Boost Foundation put forth. The opening review email states: > To be clear, the review is not about deciding governance over Boost > C++ library development. That remains in the hands of the Boost > developer community. But TBF's proposal seems entirely to be governance-related. In terms of asset stewardship, it's kind of a no-brainer to choose the organization that _didn't_ almost lose the boost.org domain name. Plus, the Alliance has Sam Darwin and he's infallible. But to the Boost Foundation's credit, I found myself agreeing with a lot of the points being mentioned. Boost _should_ consider introducing a formal CoC. Boost _should_ officially migrate to CMake and being direct here: this does mean completely abandoning b2. We need to revitalize Boost with the youth culture and to the youth, these things matter quite a bit. - Christian

9 20

Boost Asset Stewardship Review from Nick Thomson
by Glen Fernandes 06 Sep '24

06 Sep '24

Nick sent the following review to me at glenfe -at- boost.org. > From: Nick Thompson > Date: On Wed, Sep 4, 2024 at 18:26 > Subject: Fw: Boost Asset Stewardship Review > To: Glen Fernandes > > Vote: Transfer Boost Assets to the C++ Alliance > > Association with library: Contributor to math, multiprecision, > integer, random, and circular_buffer. Main contributions include > black box optimization, quadrature, and statistics in Boost.Math. > > Rationale: > > My contributions to Boost have mainly been implementation of > numerical algorithms. With each of these additions, years of future > maintenance work is implied. Even with the heroic efforts of John > Maddock, without the financial support of the C++ Alliance, these > libraries would accumulate so many open tickets that our reputation > would be badly damaged. Moreover, the utility of these libraries > would be greatly reduced. For example, there would be no way we could > support scipy's effort to expose Boost.Math to python-probably one of > the most impactful uses of Boost to date. The risk of the project > becoming completely defunk or slowly drifting into irrelevance > without continued financial support is extremely high. So as long as > the C++ Alliance is funding the maintenance, they should have the > most say in the continued operation of the library. > > Nick Thompson Nick, thank you for contributing a review. - Glen

2 1

Boost Asset Stewardship Review begins 09/03
by Glen Fernandes 05 Sep '24

05 Sep '24

Everyone, The formal review for the stewardship of Boost assets begins next week, September 3rd. For reference, the review schedule is: https://www.boost.org/community/review_schedule.html The C++ Alliance submitted the following proposal: https://cppalliance.org/pdf/Fiscal-Sponsorship-Proposal.pdf Also attached to this email as: CplusplusAllianceFiscalSponsorshipProposal.pdf The Boost Foundation has prepared a proposal for the community's consideration that is waiting on review from all board members and will be posted before the end of day tomorrow (08/30, by 5pm EST). A follow up email will be posted when it is available so that it has visibility on the Boost developers list and the Announcement list. The review, like our C++ library formal reviews, is open to everyone to participate. The official review start announcement email next week will detail the process for participation. Thank you, - Glen

5 8

[iostreams] Custom allocator support for compression filters
by Daniel Boehme 04 Sep '24

04 Sep '24

Hello everyone, I'm currently looking into custom allocators with the boost::iostreams::gzip_compressor and now need some help understanding why the code is the way it is. My problem is that I need to control how zlib internally de-/allocates memory. It seems to have support for using custom de-/allocation functions. And iostreams seems to have used it some time ago. However, passing the custom allocator to zlib has been disabled in this commit: https://github.com/boostorg/iostreams/commit/95baf782098f0dee00cc7ca6f62b9b… Does anyone happen to know what has been non-conforming and why it was disabled? I could not find any information about that in the code, on the mailing lists, or anywhere else in the internet. I'm tempted to submit a patch that enables it, but for that I need to understand the reasons behind that deliberate decision. Any hint is welcome. Thank you very much. Daniel B?hme

2 1

[boost.cobalt] Cobalt not building with b2 on Windows
by Andreas Weis 02 Sep '24

02 Sep '24

Hi everyone, It's my understanding that Cobalt is *not* a header-only library, yet it seems that it is not built as part of the b2 build. I'm building Boost with b2 on Windows (MSVC 2022, version 19.41) and it seems that Cobalt is not being built properly. I am using the following command line: b2 --toolset=msvc-14.3 --build-type=complete architecture=x86 address-model=64 --stagedir=stage -j 8 As far as I can tell, this works correctly for all libraries except Cobalt. While b2 does list cobalt as part of the "Component configuration" listing in the output: - atomic : building - charconv : building - chrono : building - cobalt : building [...] But I get neither binaries nor a folder cmake/boost_cobalt* with this. It also seems that the Cobalt binaries are not part of the distribution at https://sourceforge.net/projects/boost/files/boost-binaries/. Am I doing something wrong? Is Cobalt supposed to be part of the b2 build or is there another way to consume the non-header-only parts of the library? Best regards, Andreas

3 3

Boost.Compute broken in 1.86.0 because of UUID changes, 1.86.1?
by Peter Dimov 30 Aug '24

30 Aug '24

Because Boost.Compute (boost/compute/detail/sha1.hpp) uses an implementation detail of Boost.UUID (boost/uuid/detail/sha1.hpp), and because I changed the implementation to fix an endianness issue, <boost/compute.hpp> now causes a compile error in 1.86.0, as reported in https://github.com/boostorg/uuid/issues/166 https://github.com/boostorg/compute/pull/887 https://github.com/boostorg/compute/pull/888 https://github.com/boostorg/compute/issues/889 Users are demanding we issue a point release to fix this. It will have to include https://github.com/boostorg/compute/pull/887 and https://github.com/boostorg/compute/pull/893 What do release managers think?

10 14

Inter pod communication using shared memory
by Murali Bathina 30 Aug '24

30 Aug '24

Hi all, Is Boost supports inter pod communication using shared memory or other ways like boost interprocess communication. Looking inputs on this. Regards, Murali ________________________________ This e-mail message may contain confidential or proprietary information of Mavenir Systems, Inc. or its affiliates and is intended solely for the use of the intended recipient(s). If you are not the intended recipient of this message, you are hereby notified that any review, use or distribution of this information is absolutely prohibited and we request that you delete all copies in your control and contact us by e-mailing to security(a)mavenir.com. This message contains the views of its author and may not necessarily reflect the views of Mavenir Systems, Inc. or its affiliates, who employ systems to monitor email messages, but make no representation that such messages are authorized, secure, uncompromised, or free from computer viruses, malware, or other defects. Thank You

4 6

glibc version mismatches in CI
by Jeff Trull 28 Aug '24

28 Aug '24

Hi folks, While reviewing the Modular Boost changes for Wave I noticed that our CI is now failing - and we're not alone in this. It looks like the version of glibc in some of the old Ubuntu containers, which are required to compile against old versions of gcc, is incompatible with the Node executable that runs actions/checkout@v2 (and 3 and 4). You might see errors like this: /__e/node20/bin/node: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.28' not found (required by /__e/node20/bin/node) The Github blog discusses the change here <https://github.blog/changelog/2024-03-07-github-actions-all-actions-will-ru…> At least one brave pioneer, Andrey Semashev, has made updates to make CI green again in a handful of libraries, but I haven't seen it discussed on the list. Is there a fix other than "rewrite using manual checkout"? I managed to implement the workaround described in the blog post by adding these lines close to the top of ci.yml: env: ACTIONS_ALLOW_USE_UNSECURE_NODE_VERSION: true Though it seems unwise to rely on in the long run. Best, Jeff

5 5

Governance review
by David Sankel 26 Aug '24

26 Aug '24

The Boost Foundation approved the following motion relating to using the library review process for the governance/fiscal entity decision with 8 in favor and 0 against. MOTION: Support handling the governance question with the following process recommendations: - There should be a period (maybe a month) with a request for proposals. - These proposals should answer questions such as “What problems is this organizational change attempting to solve? How is this in line with Boost’s mission and values? What will the impact be for current volunteers? How does this proposal meet the changing needs of the Boost and wider C++ communities? What risks are there with this approach and how can they be mitigated? How will the greater C++ community react to this development?” - Proposal writers are encouraged to publish their proposals early and use feedback to refine them until the official review period is underway. - The proposals should be specific about how expenses will be financed, how decisions are made, and how decision makers will be put in place. - For fiscal entities, structure and bylaws should be stated. - All proposals should be reviewed during the same period. - The greater C++ community should be aware and invited to participate in the discussion. - The review period should be 20 days. - We want this to be a civil discussion and encourage everyone to make this a reality. Presume that others in the discussion are acting in good faith. -- David

6 7

Request for information regarding the Boost Foundation
by Robert Ramey 26 Aug '24

26 Aug '24

checking the Boost Foundation website I find some information such as https://sites.google.com/boost.org/boost-foundation/contact which lists the board of directors. Is there more complete information such as: a) link to legal documents such as articles of incorporation, 501(c)3 non-profit paperwork etc? b) Bylaws which among other things would describe the procedure for selection of members of the board, listing what the powers of the board are, etc. c) financial statements for recent years d) List of financial oblications that the foundation has committed to e) any other useful stuff Robert Ramey

3 2

Getting Started with Modular Boost Library Maintenance
by Alain O' Miniussi 26 Aug '24

26 Aug '24

Hi At the bottom of "https://github.com/boostorg/wiki/wiki/Getting-Started%3A-Overview" (why the 2 "wiki"?) there is a "Getting Started with Modular Boost Library Maintenance" link pointing to missing https://svn.boost.org/trac/boost/wiki/StartModMaint. Where is the page gone ? Thanks ---- Alain Miniussi DSI, Pôles Calcul et Genie Log. Observatoire de la Côte d'Azur Tél. : +33609650665

2 2

Stewardship Review Request
by Vinnie Falco 21 Aug '24

21 Aug '24

Recently the Boost Foundation offered the community two choices of organizations for stewardship of Boost's shared resources: itself, and The C++ Alliance. The project needs a decision, in order that its future may be determined. The Formal Review Process is typically called upon to answer the question of whether a library should be accepted into the collection. I have proposed that we use the same process to determine the question of stewardship. It is not perfect, yet it is both familiar and enduring. Although there are two designated review wizards, one is unavailable and the other is traveling. And review wizards have never been called upon to oversee non-library reviews. Therefore, I would like to add a formal review to the calendar for the following days, inclusive: Monday August 19, to Wednesday, August 28 Here are some review managers who I believe are well-suited for the task: Ion Gatzanaga John Maddock Glen Fernandes Peter Dimov If Glen or Peter accept, it would be appropriate for them to first resign from the Boost Foundation board. Thanks

18 41

Modular Boost building next steps.
by René Ferdinand Rivera Morell 19 Aug '24

19 Aug '24

After some weeks of testing and addressing review comments from authors I have now marked PRs for supporting modular building and use of 156 Boost libraries. There are 2 libraries (multiprecision and utility) that are not ready yet, as they depend on other PRs. After the testing and review I've also concluded that authors (and owners) can merge all ready PRs without waiting for the tool specific PRs. It turned out there were no dependency issues between them. Hence the process is now: * The 1.86 release happened!! * Authors further review and merge the ready PRs. * I fix any fallout from that. * I create subsequent PRs for the global B2 Boost build infrastructure to remove the old non-modular dead code. * I fix any fallout from that. * The 1.87 release happens. Thank you everyone for the help so far. In particular Peter Dimov and Andrey Semashev for the many early comments across various PRs that helped me work out the kinks of the draft PRs. -- -- René Ferdinand Rivera Morell -- Don't Assume Anything -- No Supone Nada -- Robot Dreams - http://robot-dreams.net

2 2

Another question about Boost Documentation
by Robert Ramey 19 Aug '24

19 Aug '24

There are many places where the boostbook xml/xsl files make reference to external files that we have no control of. Here is an example from modular-boost/tools/boostbook/xsl/docbook.xsl <?xml version="1.0" encoding="utf-8"?>  <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:xi="http://www.w3.org/2001/XInclude" version="1.0"> <xsl:import href="http://docbook.sourceforge.net/release/xsl/current/common/common.xsl"/> <xsl:include href="reference.xsl"/> ... This means that if something changes in docbook.sourceforge.net/release/xsl/current/common/common.xsl We'll have problems when we try to build documentation. This recently happened to me and it was a bitch to find. I spent some time looking around for the right way to fix this and came upon the concept of XML catalogs as explained here: https://en.wikipedia.org/wiki/XML_catalog#Example_Catalog.xml Seems to me that the maintainer of boostbook should verify that my understanding is correct and update boostbook files accordingly. Actually, I'd be grateful to any insight on this subject that anyone might provide. Robert Ramey

2 1

Re: [boost] [compute] Maintenance status
by René Eng 18 Aug '24

18 Aug '24

Hi all I am no expert in OpenCL nor GPGPU, but very interested in this topic and would love to learn more about it. I volunteer to take care of the maintenance of this library. Since I have no experience with the Boost way of handling PRs etc., I guess would need some support from an experienced library maintainer in the beginning. Until now I was a silent reader here, so let me shortly introduce myself: My name is René Eng, 57 years old, living in Switzerland. I am working as a C++ developer for more than 20 years, in the high performance/low latency area. I have experience with some other Boost sub-libraries, in the past also used b2 to build Boost when there were no packages available yet. If there is no-one else with more experience in this topic, who wants to take over this library, I would. This week I am on holiday, so I would actually start to take a closer look into it next week. Best regards René Von meinem iPhone gesendet > Am 21.07.2024 um 17:04 schrieb Joaquin M López Muñoz via Boost <boost(a)lists.boost.org>: > It was brought to my attention that Boost.Compute seems to be all but abandoned: > no updates in three years, more than 100 issues filed, 27 unattended PRs. This is a > shame given that the library looks pretty popular based on GH stars and references > on Internet. Are there volunteers to take on maintenance of the library? > > Best, > > Joaquin M Lopez Munoz > > > _______________________________________________ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

2 2

Option 1: Alliance stewardship of Boost
by Vinnie Falco 17 Aug '24

17 Aug '24

I believe this is important enough that it needs a thread of discussion split from the original at https://lists.boost.org/Archives/boost/2024/08/257347.php Some important details seem to have been lost in the conversation. I will summarize the Alliance position in a nutshell: The Alliance will become Boost's steward. Then, we shall assist the Boost Software Commons (a new non-profit created on March 1, 2024) to attain financial independence. Finally we will transfer the shared assets to this new non-profit. Also, I love Boost and I would like the opportunity to help it become a many-generational institution singularly driven to support library development. The message below is reposted in its entirety and without modification. --- I want to start by expressing my gratitude to Kristen, who kept an open and friendly line of communication with me for the last several months. It is unpaid volunteer work, difficult at times, and I appreciate her effort. As a passionate contributor to Boost, I am excited to see renewed growth and positive change in the project. The Boost Foundation has generously offered that the community may determine if the Alliance should be the steward of Boost’s shared resources. The term steward instead of owner is deliberate, as the former reflects the behavior which respects the Boost tradition of consensus-driven decisions. In this communiqué I would like to explore what option 1 looks like from an operational perspective (wearing my Alliance president hat) and then outline my opinion as the author of four Boost libraries. The Alliance is already the largest financial sponsor of the Boost project. Going with the first option means that our relationship to Boost would become formal. What would happen is this: 1. The Alliance becomes the registrant of the boost.org domain. This may take time, but effectively immediately after going with option 1, the Alliance shall fulfill our Domain Name Purchase Agreement under substantially similar terms including the launch of the Beman Scholarship Fund (if there is agreement). The Alliance shall reimburse the Foundation for any and all reasonable legal expenses incurred for both changes of domain ownership, including the estate fees. 2. The Alliance assumes all costs and responsibility to ensure that the boost.org domain registration does not expire, the SSL certificates are renewed and up to date, and that quarterly transparency reports are published to the mailing list apprising the community on the status of its registration. 3. The Alliance assumes all costs and responsibility for maintaining Boost’s cloud services (“Services”). This includes but is not limited to the wowbagger server, the new website, the new mailing list service, the existing mailgun account, and other services which may be required to support Boost’s infrastructure. The mailing list will be upgraded but continue to function as it is currently. Quarterly transparency reports will be published to the mailing list detailing the ongoing expenses and condition of these resources. 4. While the Alliance is the steward of the domain and cloud services, the content of the website and related web applications, such as the release building process, is controlled by the Boost GitHub Organization. Including but not limited to the repositories here: https://github.com/boostorg/website https://github.com/boostorg/website-v2 https://github.com/boostorg/website-v2-docs Changes made to these repositories will go through the existing pull request and review process, which requires community consensus. The Owners, defined as the set of users in the Boost GitHub Organization which have the Owner role, maintain the responsibility for determining consensus. 5. When the Boost community cannot achieve consensus, the responsibility for making a directional decision shall pass to the Boost Software Commons (“Commons”), a 501(c)(3) non-profit registered in Delaware on March 1, 2024, which is not controlled by the Alliance and whose board currently consists of Boost authors. The Commons is now in hibernation until it is needed. 6. The Alliance shall endeavor to help the Commons become capable of independently financing Boost’s infrastructure. The Services cost about $13,000 a year to run, excluding wowbagger and the downloads hosting costs. Our plans include: * Establishing a Boost Patreon * Sales of Boost-branded products at conferences and by mail * Soliciting donations from corporate and private sponsors * Optimizing the Services to reduce cost In all cases, proceeds from fundraising shall go directly to the Commons. 7. When fundraising levels reach the threshold necessary to finance the Services, or earlier upon request by the Commons, the Alliance shall transfer ownership of the boost.org domain to them. At the Commons’ option, the Alliance may continue administering the Services. Why The C++ Alliance? I believe that the Boost Foundation’s governance rules and board composition are simply not structured to put the best interests of Boost first, as can be seen from their own published minutes. The Boost project has been in decline for several years and the Alliance would like the opportunity to do something about it, in a way that is consistent with the project’s values. As our plans require significant financial investments (which we are happy to make), changes are needed. Option 1, Alliance stewardship of shared assets, provides Boost with the opportunity to refresh the foundations of the organization with new ideas, talent, and resources. It offers rescue from stagnation and the rare opportunity to restructure itself to better reflect the project’s changing needs from its inception 26 years ago. While I am excited at the possibility of realizing a dream to increase Boost participation, I am also mindful of the enormous responsibility this comes with. Fortunately I will not have to bear this alone, as there are many new and existing volunteers who are ready to support Boost going forward and ensure its longevity. Thank you for your support!

10 20

[release] Boost.1.86.0
by Marshall Clow 16 Aug '24

16 Aug '24

Release 1.86.0 of the Boost C++ Libraries is now available. These open-source libraries work well with the C++ Standard Library, and are usable across a broad spectrum of applications. The Boost license encourages both commercial and non-commercial use. The release contains numerous enhancements and bug fixes for existing libraries. For details, including download links, see <http://www.boost.org/users/news/version_1.86.0> You can also download directly from: <https://archives.boost.io/release/1.86.0/source/> To install this release on your system, see <http://www.boost.org/doc/libs/release/more/getting_started/index.html> Thanks to everyone who participated in this release. -- The Boost Release Team Marshall Clow, Glen Fernandes, Ion Ion Gaztañaga

6 7

[Boost][BGL] new planar_vertex_coloring.hpp ?
by hermann＠stamm-wilbrandt.de 15 Aug '24

15 Aug '24

I have some experience in using BGL and porting my non-BGL graph code to BGL. I want to create pull request for generating random maximal planar graphs. I have 1994 technical report non-BGL implementation on gihub. So before porting that, I want to get some experience on the Boost pull request and review process. I made use of the many planar graph algorithms in straight_line_graphviz.cpp gist: https://gist.github.com/Hermann-SW/99d151a273d290ee0d843c79b2da26a8 So I thought on a providing planar graph vertex coloring algorthm(s) as handson. I would start by taking https://www.boost.org/doc/libs/1_85_0/libs/graph/doc/sequential_vertex_colo… as a template for "planar_vertex_coloring.hpp". My plan is to first port my existing fast linear time "six_coloring()" https://github.com/Hermann-SW/planar_graph_playground/blob/main/c%2B%2B/und… and learn about the review process with it. Later I would implement one of the several linear time "five_coloring()" algorithms: https://en.wikipedia.org/wiki/Five_color_theorem#Linear_time_five-coloring_… And probably the quadratic time "four_coloring()" algorithm mentioned there as well. I looked at commits in Boost graph directory and there is not that much recent activity. Is my plan and the steps outlined the right way to start? Regards, Hermann Stamm-Wilbrandt.

1 3

Recommended way of doing concurrency with Boost
by Thomas Fowlery 14 Aug '24

14 Aug '24

Hi all, I'm planning to start working on a new Web3 project and I'm trying to decide how I should approach doing concurrency with C++ and Boost. It seems like using callback-passing style with Asio has been pretty popular historically. However, having worked with other modern languages with first-class async support, this feels a bit primitive. I've heard about C++20 coroutines and it seems like Boost has a library for it (Cobalt). However, it's relatively new, so I'm curious if anyone had experience with it and is it mature for production. I see that Asio also has coroutine support, so what's the difference? The third option I'm considering is using fibers. I like this option in principle because the resulting code is very clean and looks like normal synchronous code. However, I haven't seen many big examples/projects using Boost.Fiber with Boost.Asio. Is this something people are doing out in the wild? Does Asio support Fibers well? Best regards, Thomas

9 12

Re: [boost] [Boost-users] [release] Boost.1.86.0
by Vinnie Falco 14 Aug '24

14 Aug '24

On Wed, Aug 14, 2024 at 11:46 AM Andrea Bocci <fwyzard(a)gmail.com> wrote: > Right, because posting to a social network owned by an extremist, fascist, racist and nazi-apologist should do great for improving Boost's image. I completely understand your concerns about this particular platform. Please understand that our goal in sharing updates here is simply to reach more people and make Boost's work visible, not to endorse or align with any particular ideology. I think a strong online presence can help us connect with more people who care about our libraries, and that ultimately benefits everyone involved. That being said, I appreciate your feedback and in the future we should definitely consider the nuances of social media platforms when deciding how to share information. Perhaps we can explore additional ways to share updates that still reach a wide audience, while also being mindful of the values and principles we want to uphold? Thanks

1 0

[unordered] GDB pretty-printer display bikeshedding
by Braden Ganetsky 14 Aug '24

14 Aug '24

Hi all, I want some opinions on the display printout for the GDB pretty-printers I'm working on, for the Unordered library. I have a sample printout in this GitHub gist here. (https://gist.github.com/k3DW/ead86d748aa4c4bba3f9f67f09521ba5) Everything at this link is already implemented and functional in my branch. I want opinions on how it looks. I have a few specific questions for everyone, but I'll take any other comments that don't belong with these questions below. 1. For the container display format, I matched what the standard library containers do. Should the beginning be shortened to `boost::unordered_map` instead of the current display of `boost::unordered::unordered_map`? The same question applies to all of the other containers. Does the middle namespace `unordered` cause too much visual noise? 2. For the iterators, is `iterator = {...}` a good enough format? Or should this iterator also specify the container type it came from instead of just `iterator`? I prefer it as I wrote it, but I am only one member of the community. 3. Any suggestions for end iterators other than simply `{ end iterator }`? Again, I like it this way, but I want to know if other people feel similarly. 4. To print the stats, I implemented a custom GDB command called "print_stats" that behaves exactly like "print", except it prints an open-addressing container's stats instead of its elements. Is the name "print_stats" alright to use in this scenario? Or should it be something like "boost_unordered_print_stats" to mitigate against name collisions? Thanks, Braden

1 0

Bug fixed inline GDB pretty printing
by Niall Douglas 13 Aug '24

13 Aug '24

Re: my previous guide to writing inline GDB pretty printers, it turns out it had bugs. Here is how to fix them. Firstly, my thanks to Braden Ganetsky for reporting the bugs, then pair programming over Slack with me late last night to diagnose and fix the issues. We have cowritten a conversion script which we now believe is actually correct -- it takes a Python GDB pretty printer, and emits a C (not C++) header file with all the correct markup. It can be found at: https://github.com/ned14/quickcpplib/blob/master/scripts/generate_gdb_print… The first bug fixed is correct escaping: we need to double escape the original Python in the right kind of way to cause the escaped inline assembler block to emit the right escaped text for GDB to load it correct as Python. Getting the double escaping correct is tricky, but we think we have it now. The second bug fixed is correct composure of multiple inline GDB pretty printers - Braden found only the first was having any effect. It turns out this is due to a misreading of the GDB docs from https://sourceware.org/gdb/current/onlinedocs/gdb.html/dotdebug_005fgdb_005… where this example: ``` asm( ".pushsection \".debug_gdb_scripts\", \"MS\",@progbits,1\n" ".byte " XSTRING (SECTION_SCRIPT_ID_PYTHON_TEXT) "\n" ".ascii \"gdb.inlined-script\\n\"\n" ".ascii \"class test_cmd (gdb.Command):\\n\"\n" ... ``` ... does not make it clear that the string "gdb.inlined-script" is actually the unique identifier of that script used to eliminate duplicates. It needs to be unique per inlined script unless you specifically want duplicates, and our Python converter above has remedied this. Generally you ought to name it after your library and maybe possibly a git SHA or version depending on how unstable your library is, and ensure that the pretty printer matches only that version of your library. Thanks once again to Braden for his help. Note that the Outcome GDB pretty printer which has shipped in the pending Boost release is buggy and will not work properly. The next Boost release will fix it. You can of course copy the fixed pretty printer from the github repo over this Boost release. Niall

1 0

[release] Boost 1.86.0 Release Candidate 1 is available
by Marshall Clow 13 Aug '24

13 Aug '24

The first release candidates for the 1.86.0 release are now available at: <https://boostorg.jfrog.io/artifactory/main/release/1.86.0/source/> The SHA256 checksums are as follows: 2575e74ffc3ef1cd0babac2c1ee8bdb5782a0ee672b1912da40e5b4b591ca01f boost_1_86_0_rc1.tar.gz cd20a5694e753683e1dc2ee10e2d1bb11704e65893ebcc6ced234ba68e5d8646 boost_1_86_0_rc1.zip 413ee9d5754d0ac5994a3bf70c3b5606b10f33824fdd56cf04d425f2fc6bb8ce boost_1_86_0_rc1.7z 1bed88e40401b2cb7a1f76d4bab499e352fa4d0c5f31c0dbae64e24d34d7513b boost_1_86_0_rc1.tar.bz2 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

6 6

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

Misunderstandings about the Boost Foundation
by David Sankel 13 Aug '24

13 Aug '24

Hi all, I want to address some misunderstandings surrounding Jon Kalb’s departure, foundation revenue sources, and boost project initiatives. First, Jon’s exit from the Boost Foundation was not the result of Jon committing a code of conduct violation. Out of respect for his privacy, I don’t want to detail the rationale unless Jon agrees that it should be public. Second, Boost Foundation revenue comes from sources beyond C++Now proceeds; individual donations and corporate matches make up 41% of revenue. Finally, I’d like to address the idea that the foundation board is distracted with the conference and pays no attention to the Boost project. A lot of what we do isn’t visible, so it is understandable how someone might come to this conclusion. However, here is a sample of Boost project-specific work we’ve done over the past couple of years: - Retired an old server that was no longer being used - Brought on a contractor who provided advice on how to migrate Wowbagger’s functionality off of legacy platforms - Handled outages due to Wowbagger’s hard drive failures - Addressed a GitHub issue where a large file was exceeding our limits - Created a discourse.boost.org so the Boost community could experiment with a mailing list alternative - Solicited estimates from CDN vendors when our current sponsor said they’d no longer be able to provide free bandwidth - Held brainstorming sessions on how we could help the Boost project better meet its objectives The fact that foundation work isn’t widely known by others involved in the Boost Project is a problem. I’d like to find more effective means to communicate the good work that’s being done. – David

2 1

[config] First steps towards C++20 modules
by Antony Polukhin 12 Aug '24

12 Aug '24

Hi, C++20 modules seem to be a good tool to improve compile times and to hide the implementation details of the libraries. I've been looking throught the sources of {fmt} library. Looks like the fmt library approach to C++20 modularization seems to fit Boost quite well. How about adding the following macro to Boost: * BOOST_BEGIN_MODULE_EXPORT - starts the scope of things to export if Boost is build as a C++20 module * BOOST_END_MODULE_EXPORT - ends the scope of things to export if Boost is build as a C++20 module * BOOST_MODULE_EXPORT - for a single entity export if Boost is build as a C++20 module As a result, if Boost is build as a module the above macros are defined in the following way: #define BOOST_MODULE_EXPORT export #define BOOST_BEGIN_MODULE_EXPORT export { #define BOOST_END_MODULE_EXPORT } Helper macro BOOST_NO_CXX23_IMPORT_STD for detecting availability of `import std` also seems useful. Macro BOOST_NO_CXX20_MODULES - for notifying the libraries that compiler does not support modules or Boost modules are not compiled. With all the above macros the Boost libraries could look like: /// header #include <boost/library_that_is_known_to_not_support_modules.hpp> #ifdef BOOST_NO_CXX20_MODULES #include <boost/library_that_supports_modules.hpp> #else import Boost.LibraryThatSupportsModules; #endif #ifdef BOOST_NO_CXX23_IMPORT_STD #include <iostream> #else import std; #endif namespace boost { namespace detail { template <class T> bool try_do(const T&); } BOOST_BEGIN_MODULE_EXPORT template <class T, class From> bool try_lexiacal_convert(const From& f, T& to) { /*impl*/ } template <class T, class From> T lexiacal_cast(const From& f) { /*impl*/ } BOOST_END_MODULE_EXPORT } /// module src file export module Boost.MyLibraryName; #ifdef BOOST_NO_CXX20_MODULES #error ??? #endif #include <boost/my_library.hpp> -- Best regards, Antony Polukhin

5 14

Question regarding Boost Documentation
by Robert Ramey 11 Aug '24

11 Aug '24

I think I recall that from time to time I see reference to a "global" (my term) documentation build which builds an html tree of all the boost libraries whose documentation has been built with boostbook. But in perusing the website I don't find any such documentation. What am I missing here? Robert Ramey

9 26

[circular_buffer] Is it usable in embedded contexts?
by Andrzej Krzemienski 11 Aug '24

11 Aug '24

Hi Everyone, This is a couple of questions about Boost.Circular_buffer, but also about Boost in general. A colleague of mine says he needs a ring buffer for usage in the embedded context, and I am investigating why he chooses to write his own rather than using Boost.Circular_Buffer, even though he knows the latter exists. It is a natural expectation for containers like static_vector/inplace_vector, array, circular_buffer to be a natural fit for the embedded contexts, as, at least in principle, they should not require any memory allocation. Question 1: Is Boost a suitable place for libraries targeting systems where exceptions, RTTI and memory allocation are banned? I tried to check what Boost.Circular_Buffer offers, and I was surprised that it requires at least one, initial allocation. Maybe I could get away with a custom allocator, but then why do we have static_vector, rather than the advice to use std::vector with "in-place allocator"? Question 2: Is it a reasonable expectation of a ring buffer to not require allocations? I tried to find more details in the docs, but I found that the entire reference documentation for class template circular_buffer is missing from the docs. Question 3: Is Boost.Circular_Buffer actively maintained? The last commit is from three years ago. One thing, my colleague says, that puts him off from even considering Boost.Circular_Buffer is the amount of headers that circular_buffer.hpp directly and indirectly includes. This dwarfs the number of headers in his entire project. Also the fact that Boost.Circular_Buffer includes the standard headers is problematic, as some standard-mandated headers are not available on some embedded platforms. A lot of these dependencies are for emulating C++11 features, like static_assert, which may not be necessary if we assume some C++11 level of compiler conformance. Question 4: Maybe there would be a value, at least for some Boost libraries, to provide a single-header, header-only variant that works under some assumptions, like C++11 compiler? My colleagues use case is that, because removals from the buffer can occur asynchronously, when doing a pop_back() there is no way to be sure that the buffer is non-empty, so this would require a function that does the check and the pop_back at one go. I am interested to learn what others think about this. Ideally, I would like for Boost to be in a state where developers prefer to use it rather than writing their own popular components. Regards, &rzej;

4 3

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

New Logo Discussion
by Vinnie Falco 09 Aug '24

09 Aug '24

Hi. It is CppCon 2024 season, and the C++ Alliance is working on letting people know all the new and exciting things happening in Boost. We're doing this with Boost labeled conference shirts, and a beautiful brochure. You can see a draft of this promotional piece here (note: work in progress): https://cppalliance.org/pdf/Boost-Brochure-CppCon-2024.pdf The new Boost logo was developed by the Alliance, and a community consensus is needed if we are to fully move forward with its use. I am hoping this will spark the necessary discussion. Here are things to consider: * The logo is professionally designed by https://grainandmortar.com/ at a cost of $12,000 * Peter Dimov likes the image (this should not be construed as his endorsement or opposition to any of the above). * The image is a trademark of The C++ Alliance: https://tsdr.uspto.gov/#caseNumber=98417319&caseSearchType=US_APPLICATION&c… * Usage of the logo is governed by our Logo Usage Policy, a product of legal review at a cost of $4,000: https://www.boost.io/doc/contributor-guide/docs/logo-policy-media-guide.html * The Logo Usage Policy allows free usage without permission in Boost-related contexts. Otherwise, explicit written permission from the Alliance is required. * Trademark ownership by a registered entity with sufficient resources is necessary to protect the mark, which David Sankel alludes to here: https://lists.boost.org/Archives/boost//2024/03/256092.php * Adopting this logo costs Boost nothing. If our proposed arrangement stops working for the community, the libraries can easily adopt a different logo (including the old one, or none). Put simply, I am asking the Boost community to entrust The C++ Alliance.with the responsibility of establishing and maintaining this new Boost logo. Thanks :)

18 63

Alumni Program
by Vinnie Falco 09 Aug '24

09 Aug '24

All: I've been engaged more with long-time members of the Boost community, and something which I now realize is the extraordinary level of camaraderie and brotherhood which sprang from the early years of Boost evolution. Boost was a family and like all families, it has changed. People left, new people joined, priorities shifted, and such. Contribution to the libraries is something special, so I would like to introduce an idea. The "Boost Alumni Program." Like a college alumni program this is designed to help Boost contributors stay in touch over the years. There could be a mailing list, and a program administrator who is tasked to keep track of everyone, including their email and phone number. They can keep contact and track changes in careers, new projects, and so on. The goal here is to help maintain the relationships of contributors over time, even when they have moved on from the project for various reasons such as a new job or new life circumstances. I don't know all the details, but would anyone find value in such a program? Would anyone want to participate? Would anyone be against this? Thanks

3 2

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

[outcome] Inline GDB pretty printing support
by Niall Douglas 08 Aug '24

08 Aug '24

Dear Boost, The biggest new feature to land into Outcome since it went ABI stable is inline GDB pretty printing support, whereby we embed into all binaries using Outcome the Python script to display the state of `result<>/outcome<>`. As Outcome uses a layered inheritance technique to match triviality of member functions from its configured types, having to click down through the layers to discover the state was always frustrating. MSVC has long shipped with a visualiser to eliminate this, so now support for GDB matches MSVC support. The relevant implementation file can be found at: https://github.com/boostorg/outcome/blob/master/include/boost/outcome/outco… I would appreciate any testing and reporting of any issues or bugs before the 1.86 bugfix window closes. It should "just work" once you have enabled inline script loading in your `.gdbinit`. Thanks, Niall

10 19

[release] Master branch is closed for ALL changes
by Marshall Clow 08 Aug '24

08 Aug '24

Please do not commit anything to the master branch. Other branches are always fine. The 1.86.0 release is scheduled for next Wednesday, 15-Aug. — Marshall

2 1

How to use the O(1) remove_edge(typename Config::out_edge_iterator iter)
by hermann＠stamm-wilbrandt.de 08 Aug '24

08 Aug '24

I looked at runtime statements here: https://www.boost.org/doc/libs/1_85_0/libs/graph/doc/using_adjacency_list.h… Fore remove_edge() there is no O(1) option listed. On the other hand in Boost graph code I see this O(1) remove_edge() in boost/graph/detail/adjacency_list.hpp: template < class Config > struct directed_edges_helper { ... // O(1) inline void remove_edge(typename Config::out_edge_iterator iter) { std::cerr << "foobar" << std::endl; typedef typename Config::graph_type graph_type; graph_type& g = static_cast< graph_type& >(*this); typename Config::edge_descriptor e = *iter; typename Config::OutEdgeList& el = g.out_edge_list(source(e, g)); el.erase(iter.base()); } }; So my questions is for which graph and how I can make use of that O(1) function to remove an edge. It seems to be for directed graph only. While I need it for undirected graph, being able to use that O(1) function for directed graph would be a first step. Regards, Hermann Stamm-Wilbrandt.

1 2

GPU Library Utilities
by Matt Borland 07 Aug '24

07 Aug '24

By popular demand Boost.Math has begun adding support for CUDA (NVCC and NVRTC) and SYCL. Unfortunately to use all of these platforms you can not really use std:: as CUDA has utilities (e.g. <type_traits>) in cuda::std::, containers (e.g. tuple) in thrust:: and mathematical functions in the global namespace. There are also completely missing features like <limits>. To work with this we have started creating new headers that implement these features and workarounds such as: 1) limits: https://github.com/boostorg/math/blob/develop/include/boost/math/tools/nume… 2) Tuple: https://github.com/boostorg/math/blob/develop/include/boost/math/tools/tupl… 3) General configuration: https://github.com/boostorg/math/blob/develop/include/boost/math/tools/conf… Now in the code base for example instead of using std::pair you use boost::math::pair which aliases to either thrust::pair or std::pair depending on context. As we continue to build out this support we know we are going to create more headers for compatibility, and feature completeness. I thought these could be useful to other libraries so I asked John Maddock about adding copies of them to Boost.Config. He said that's not an unreasonable home for them, but I should consult the ML. My questions then are: 1) Would these utilities be useful to you? 2) If yes, do you think that Boost.Config is the right home for them? I posted a similar question on Slack yesterday and Joaquin suggested Boost.Compute. I don't think that's the right fit because these would be out of scope, the library is extremely heavy, and it's been over 5 years since the last commit from a maintainer. I would also rather not propose and go through review on a Boost.GPU_Utils, but with sufficient demand it could be worth the effort. Please let us know what you think, and thanks for your time. Matt

4 5

Issues (and possible fix) with Bimap
by Ignacy Gawedzki 06 Aug '24

06 Aug '24

Hi, I've run into issues with code using Bimap and GCC optimizations. The description has been submitted both as a bug report to GCC (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115767) and as an issue in Boost Bimap (https://github.com/boostorg/bimap/issues/43) While trying to reduce the Bimap code to find a minimal example, I've found what looks like a proper bug in Bimap and have created a pull request (https://github.com/boostorg/bimap/pull/45) It's now been two weeks and the PR is still awaiting approval, so I thought maybe I better write about it here as well. I suspect the issues might come from both a bug in GCC optimizations and from Bimap, because they seem to be gone when I compile with the latest GCC (which received some optimization-related patches lately) and the patched Bimap, both on aarch64 and x86_64, but I can't tell for sure. Cheers, Ignacy

2 1

A Follow Up to My Original Note Re The Future of Boost
by Kristen Shaker 06 Aug '24

06 Aug '24

Hello Everyone, Thank you for patiently waiting while we had the opportunity to discuss things. Many of you have not heard my name before - this is largely because as a board, we do much of the non - dev work behind the scenes, such as administrative tasks like paying bills. However, I do want to take this opportunity to introduce myself quickly and to emphasize that - should anyone wish to reach out to me directly - I am happy to correspond via phone or email. My name is Kristen - I spent many years at Google on the C++ Core Libraries Team. I am heavily involved as an organizer in CppCon and C++Now. If anyone is curious about what I did at Google, I did give a talk <https://www.youtube.com/watch?v=torqlZnu9Ag> on automated refactoring and Clang Tidies that you can find on Youtube. My duties as Board Chair involve sending out meeting agendas, taking meeting notes, and collating meeting minutes. It is not our role to lead, but rather to support the Boost project. The leadership and direction of the Boost project has and should remain with the Boost Developers. The original Boost Steering Committee home page articulates its purpose as follows: “In the Boost community decisions have always been made by consensus and individual members have shown leadership by stepping forward to do what they felt needed to be done. Boost has not suffered from a lack of leadership or volunteer participation. It is not the role of the Steering Committee to inhibit this kind of spontaneous leadership and action, which has served Boost and the wider C++ community so well. On the contrary, it is the role of the Steering Committee to facilitate community-based leadership and decision making. The role of the Committee is to be able to commit the organization to specific action either where funds are required or where consensus cannot be reached, but a decision must be made.” We generally encourage any Boost Developer who would like to be more involved in administrated or organizational decisions to consider joining the board. We have multiple open board seats. Several Boost Developers are on the board and additional developers have been invited in the past - however they have decided against joining due to their distaste for the type of administrative work we do. We would love to hear more from you. Please reach out. You can reach all of us at once via boostfoundationdirectors(a)boost.org. Additionally, if you’d like to attend one of our board meetings, we regularly host guests. The C++ Alliance and the Boost Board of Directors have had their disagreements. Recently, it has become apparent - in particular via their attempt to purchase the boost.org domain name and the proposed new Boost Logo - that The Alliance would like to exert a greater sense of ownership over Boost Library assets. The desired control over assets is what I was referring to in my original note regarding their attempt to take ownership over the Libraries. While the C++ Alliance is a non profit organization, it is wholly funded and effectively controlled by one individual - Mr. Falco. The Board of Directors has a stewardship responsibility to Boost and we are wary of a single individual exerting such a level of control over the Boost Libraries. The Board has existed for many years and will continue to exist - as new members are regularly on boarded as tenured ones retire. Given the structure of the Board and the nature of the volunteer work, we believe ourselves to be the more permanent entity. Many have mentioned a desire for cool headed coordination between the two organizations. I also believed this to be the most advantageous outcome, so I reached out to Mr. Falco to establish a direct line of communication. Even now I would characterize our personal relationship as quite positive. Due to some pre-existing personality clashes, it is now our understanding that Mr. Falco believes collaboration to be an impossibility. Therefore, a large part of Mr. Falco’s motivation to acquire the domain name stemmed from a desire to cut the Board of Directors out of all future decision making processes. Given that I believed we had made great progress toward greater collaboration, I was personally gutted by this turn of events. Accordingly, we did not see a well lit path forward regarding coordination between the Boost Board and the C++ Alliance. This decision was in no way meant to minimize the great contributions The Alliance has made to the Boost Libraries. We do not want to discourage Alliance members from contributing to Boost. This is fundamentally a question about the stewardship of the Boost Library Assets. As mentioned above, the Boost Board of Directors exists largely to facilitate community based decision making. Accordingly, we feel the most appropriate thing to do at this juncture would be to let the developers make a decision on how they would like to proceed regarding what level of ownership the C++ Alliance should have on Boost Library assets. Here are what we believe to be the available options. 1. The C++ Alliance assumes control of the Boost assets, including the boost.org domain name. The Boost Foundation becomes uninvolved in any decisions related to the Boost Libraries. 2. The Boost Foundation continues to be the stewards of the boost.org domain name and related assets. New assets that are meant to be associated with the Boost Libraries are transferred to the Boost Foundation. In any matters related to the Boost Libraries, the Board will abide by any decisions made by the developers but will no longer vote themselves on issues as they relate to the Boost Libraries unless there truly is no clear consensus or path forward. There was some discussion about the assets being held in a third party non profit controlled by a subset of the Boost Developers. However, given that there are already many Boost Developers on the Boost Foundation Board of Directors, we don’t see this as a meaningful deviation from the status quo. Also as one final note, many on the mailing list expressed a distaste for the political nature of this disagreement. Of course, being involved in political spats is not why you joined Boost! We completely understand this. Believe me when I say we don’t like dealing with political disagreements either - no one does. They’re draining and they can distract from an organization’s larger mission. However, sometimes, they are truly unavoidable. We’re articulating our thought process here, not to annoy you, but so every Boost Developer has a say in how things turn out. Warm Regards, The Boost Board of Directors Also here are some answers to some of the more specific questions. There were a lot of them and I believe some were answered in the preceding paragraph. Sincerest apologies if I missed a question or two. Beman Dawes did pass away in 2020. The Boost Foundation did take action when the domain expired. In fact, Michael Caisse spent many hours on the phone with support figuring out how to pay for the bill so the website would be accessible. Additionally, he invested significant time in procuring the death certificate so we could own the domain. Progress was being made, albeit slowly.

21 41

[release] Reminder: Master Branch closes for all changes this WEDNESDAY August 7th
by Marshall Clow 05 Aug '24

05 Aug '24

For the 1.86.0 release. The calendar is here: https://www.boost.org/development/index.html — Marshall P.S. If you have change notes, don’t forget to add them to the website.

1 0

Re: [boost] A Follow Up to My Original Note Re The Future of, Boost
by John Phillips 03 Aug '24

03 Aug '24

On Thur, Aug 1, 2024 at 6:37?AM Vinnie Falco via Boost < boost(a)lists.boost.org> wrote: On Wed, Jul 31, 2024 at 1:52?PM Kristen Shaker via Boost < boost(a)lists.boost.org> wrote: > ...let the developers make a decision on how they would like to proceed Thank you, and this is very much in the Boost tradition. While the Boost Software License is likely to be the project's most impactful contribution, the Formal Review Process is a close second. Therefore, I propose that the question of custodianship be decided by a formal review. It is becoming more and more difficult to find suitable review managers who are not associated with the C++ Alliance (a self-inflicted wound, I suppose) but I nominate these as candidates: Ion Gaztanaga John Maddock Thanks ------------------------------------------------------------------------------------ I understand the desire to use something like the review process for this, but I think we need to be cautious about the differences between a software review and what we need in this case. Not that there is no way to do something similar to a review, but just to make sure we understand what the review process is good at and not good at. The intent of the review process is to let interested developers share ideas and expertise to find the best technical solution. The proposed library is the focus of the discussion but in some cases the conversation can range far from the proposal. The allowed outcomes include fully accepting the proposal, provisional acceptance with stipulations, or rejecting the proposal with constructive commentary about how it could be improved to have a more positive reception. All the participants on this list know this, but consider how the review process compares to what is needed in this conversation. We're trying to solve organizational and legal issues, instead of implementation and documentation issues. We want to decide what path would best allow us to proceed with our core tasks of producing high quality, real world usable libraries for inclusion in a broad spectrum of software uses, leading to refinement of implementation and interface so we can have a solid proposal for inclusion into the C++ standard. What organization would give the work we do the needed visibility so developers and companies around the world want to try the Boost libraries? What leadership would give our developers sufficient insight into the needs of C++ developers at large required to provide for those needs? What what resources will allow us to solve the technical and legal issues in our structure and infrastructure that we need to continue to mature and grow effectively? These aren't questions I personally have the technical and organizational expertise to judge well. Nor are they questions that someone could provide a sample implementation for during a review to illustrate a potential pitfall. They are however questions where some members have a strong personal stake and contention could cause lasting and damaging rifts between the volunteers that are the heart and soul of Boost. It is also true that reviews tend to have just the three outcomes listed above, while this process could come to conclusions no one has even thought of to mention, yet. I also think that to be useful it will need extensive involvement from as many Boost participants as possible. You can have a good technical review of a library that is dominated by half a dozen experts in the problem and techniques to address it. This review will need input from half or more of the Boost community to produce the broad buy in that such organizational decisions should get. This is again not to say it can't be done. I am only trying to make sure that we understand the possible ways a review of this sort will be far different from the normal reviews we perform. John Phillips Review Wizard

1 0

Notice of Intent To Redirect boost.org to boost.io
by Vinnie Falco 02 Aug '24

02 Aug '24

All: A consensus to launch the new Boost website was reached by both the community and the Boost Foundation. Since then, the Foundation has: * Ignored the consensus decision reached in April [1] * Prevented the C++ Alliance's attempt to secure the boost.org domain [2] * Launched the competing "Beman Project" [3] * Voted to "cut ties with the Alliance" [4] * Avoided important questions asked on the mailing list, for over a month As it is clear now that Foundation control of the boost.org domain may be harmful to Boost, the existing website will be redirected to the new website. Absent objection, this pull request to redirect boost.org to boost.io will be merged on August 5, 2024: https://github.com/boostorg/website/pull/861 Thanks [1] https://lists.boost.org/Archives/boost/2024/04/256602.php [2] https://cppalliance.org/pdf/Domain-Name-Purchase-Agreement.pdf [3] https://www.bemanproject.org/ [4] https://cppalliance.org/pdf/Boost-Foundation-Minutes.pdf

6 11

Re: [boost] A Follow Up to My Original Note Re The Future of Boost
by Adam C Getchell 01 Aug '24

01 Aug '24

> On Aug 1, 2024, at 3:31 PM, boost-request(a)lists.boost.org wrote: >> >> Here are what we believe to be the available options. >> >> 1. >> >> The C++ Alliance assumes control of the Boost assets, including the >> boost.org domain name. The Boost Foundation becomes uninvolved in any >> decisions related to the Boost Libraries. +1. My perspective is that I’d like to spend as much time possible writing code to solve scientific problems, rather than fighting with package managers, build systems, and bugs in libraries lacking maintainers to fix them. As far as I can tell, except for the efforts of particular library authors and the C++ Alliance, Boost has been largely stagnant. I support efforts to keep Boost and C++ relevant. Otherwise, folks like me will probably write new code in Rust rather than dealing with these issues. Adam P.S. To be fair, that ship has probably sailed for some of us. [1] [1] https://engineering.01cloud.com/2024/08/01/tractor-automating-the-transitio…

1 0

Master branch is now open for bug fixes
by Marshall Clow 31 Jul '24

31 Jul '24

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

7 11

Requesting permission for a trivial change to LEAF
by Emil Dotchevski 29 Jul '24

29 Jul '24

It would be nice to include in the current release this small change that marks leaf::result objects as nodiscard: https://github.com/boostorg/leaf/commit/1f745805553934cd76a241649cd9bafa277… . Thanks, Emil

1 0

[release] Boost 1.86.0 beta 1 released
by Marshall Clow 26 Jul '24

26 Jul '24

Boost release 1.86.0 beta 1 is now available at: https://boostorg.jfrog.io/artifactory/main/beta/1.86.0.beta1/source/ The SHA256 checksums are: 6c3b6b6b1760090ebd658b764c9006d9579df2a20763ede356e059fe52989277 boost_1_86_0_b1.tar.bz2 cc0e5c0fb54ea8762c2eb9fbfd185cb8ccbe1ad33c218883f9438dbe2f9a795b boost_1_86_0_b1.zip cad677f5b746bd83c68131766554b56ebf40eb7ba94823526b03820db9dbc049 boost_1_86_0_b1.7z 82b59c0ca4d3b8bbf910ffdbbf535ef738fa1d648b8ba6f2608b516a58f89c55 boost_1_86_0_b1.tar.gz Release notes (still need updates): https://www.boost.org/users/history/version_1_86_0.html Please try the beta and report any problems you encounter. Thanks to everyone who contributed to the release. Thanks especially to Sam Darwin for his help with the tools, and figuring out what happend with RC3. -- Boost Release Team

1 0

Re: [boost] [release] Boost 1.86.0 Beta 1 Release Candidate 4 is available
by tobi＠die-loews.de 26 Jul '24

26 Jul '24

1 0

[release] Boost 1.86.0 Beta 1 Release Candidate 4 is available
by Marshall Clow 25 Jul '24

25 Jul '24

[ RC3 was malformed as a result of some tooling failures ] The fourth (and hopefully final) RC for the 1.86.0 Beta release is now available. Available at: https://archives.boost.io/beta/1.86.0.beta1/source/ The SHA256 checksums are as follows: cad677f5b746bd83c68131766554b56ebf40eb7ba94823526b03820db9dbc049 boost_1_86_0_b1_rc4.7z 6c3b6b6b1760090ebd658b764c9006d9579df2a20763ede356e059fe52989277 boost_1_86_0_b1_rc4.tar.bz2 cc0e5c0fb54ea8762c2eb9fbfd185cb8ccbe1ad33c218883f9438dbe2f9a795b boost_1_86_0_b1_rc4.zip 82b59c0ca4d3b8bbf910ffdbbf535ef738fa1d648b8ba6f2608b516a58f89c55 boost_1_86_0_b1_rc4.tar.gz Changed libraries between RC2 and RC4: Boost.Process fixed some build issues on Windows 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

5 7

Boost 1.86 release notes?
by Andrzej Krzemienski 25 Jul '24

25 Jul '24

Hi Everyone, Are 1.86 beta release notes available anywhere? I recall that the beta release documentation used to be put on boost.org. Regards, &rzej;

2 1

[release] Boost 1.86.0 Beta 1 Release Candidate 3 is available
by Marshall Clow 24 Jul '24

24 Jul '24

The third (and hopefully final) RC for the 1.86.0 Beta release is now available. Available at: https://archives.boost.io/beta/1.86.0.beta1/source/ The SHA256 checksums are as follows: a632d1e1465804b26f4d73112f1142c89caf74b026395df2e63a8c8972ac3ab0 boost_1_86_0_b1_rc3.tar.gz e061d83644568178ddece4bd3e241fb2656f49d6157c5d9fbff6c2fa74b1e328 boost_1_86_0_b1_rc3.zip e7f07bbc14915469b1ef80337c16e7a592f3eb547ba2cca828253c0a32372399 boost_1_86_0_b1_rc3.tar.bz2 91dcd8f980362c1c32bf8cc547c547fb02619bea877738b478c052926edc6a2d boost_1_86_0_b1_rc3.7z Changed libraries between RC2 and RC3: Boost.Process fixed some build issues on Windows 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

1 1

[release] Boost 1.86.0 Beta 1 Release Candidate 2 is available
by Marshall Clow 24 Jul '24

24 Jul '24

Available at: https://archives.boost.io/beta/1.86.0.beta1/source/ The SHA256 checksums are as follows: c62c9ab3c448ef4ed1b45f69631e3d7cc425fca96b991e5007b3af49f84344e1 boost_1_86_0_b1_rc2.zip 7e5b42428ed30a7ac9d832e9df9f5150a29d9cffe5aebde4d4c109da89f54b77 boost_1_86_0_b1_rc2.tar.gz 8718b092b37f04a739b647d154901d923fb3c3cdcff9f793d6a472e3f8e7c647 boost_1_86_0_b1_rc2.7z cd63cd3110fafbed8c196a82dd0f72c8600bc5c7fc218ede213947da3b721c06 boost_1_86_0_b1_rc2.tar.bz2 Changed libraries between RC1 and RC2: Boost.Process Boost.Odeint 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

3 3

[release] Status of the Beta release
by Marshall Clow 24 Jul '24

24 Jul '24

We’ve had some problems with the RCs for the 1.86.0 beta. The RC1 had problems with Boost.Odient and Boost.Process. We had an RC2 yesterday, but that didn’t fix all of the Boost.Process build problems. There will be an RC3 today, which (hopefully) will fix them . If nothing else is found the beta release will be Friday. — Marshall

1 0

[release[ Boost 1.86.0 Beta 1 Release Candidate is available
by Marshall Clow 23 Jul '24

23 Jul '24

Available at: https://archives.boost.io/beta/1.86.0.beta1/source/ The SHA256 checksums are as follows: 90be7ebbaf1c81a849791eb0f49d05a9ec7dbd0ec98b974dfe31d44d811e8298 boost_1_86_0_b1_rc1.7z 543ca3b743250a8b24b25c71209cf911c35613910e78a320835c21c053212ef2 boost_1_86_0_b1_rc1.tar.gz 1bf831ed717fa3e01db6c1f104b95f5a6a8d098a4cc9e61fa6eb81969c78645f boost_1_86_0_b1_rc1.tar.bz2 f739f8761bee6006c60a39fd21ed80b7b0a681c9ed448d1ae1bb28d8d8a69659 boost_1_86_0_b1_rc1.zip 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

7 13

[Release] Master branch is closed for beta
by Marshall Clow 23 Jul '24

23 Jul '24

Master is closed for all changes. See the release schedule at: https://www.boost.org/development/index.html -- Release managers

3 4

Q2 2024 Transparency Report on Boost C++ Library
by Louis Tatta 22 Jul '24

22 Jul '24

Hello, Louis Tatta here, CEO of The C++ Alliance, Inc, a registered 501(c)(3) non-profit organization dedicated to supporting C++. This is our Q2 2024 transparency report on our charitable work for the Boost C++ Library Collection. The C++ Alliance actively seeks out highly talented and experienced C++ experts, hiring them, often full-time, so they can fully dedicate themselves to open-source projects. Our Staff Engineers maintain existing Boost libraries, develop new ones, and contribute to other Boost projects. We also employ IT experts full-time to maintain and enhance the infrastructure supporting Boost. This includes the legacy web server, the Drone continuous integration servers, deployment scripts for GitHub Actions on Boost repositories, and scripts that publish Boost releases. Additionally, we provide on-demand technical support services for Boost authors and maintainers facing infrastructure-related issues. The Boost Mailing List remains the premier venue for high-quality discussions on Boost libraries and related C++ Standards topics. The C++ Alliance continues to support the mailing lists, upgrading them to the latest Mailman version and developing an optional web-based front-end for browser-based interaction. We also manage the Official C++ Language Slack Workspace ( https://cpp.al/slack) hosting the most popular interactive discussions on Boost libraries. The C++ Alliance sponsors a paid plan to offer full history, video and audio conferencing, collaboration tools, and unlimited document storage for seventeen dedicated Boost library channels and one main Boost discussion channel. Our largest project for Q2 2024 is the ongoing development of the new Boost website. This new site will be a C++ social media portal with rich support for user-generated content and a robust back-end that provides visibility into contributions made on GitHub and the release process. Our goal is to deliver an enhanced user experience that attracts fresh talent to Boost. Notably, the website features hand-drawn graphics by our contract artist, reflecting our commitment to ensuring Boost not only functions well but also looks visually appealing. In Q2 2024 there were a total of zero Boost Formal Reviews. There were two petitions for endorsement for potential Boost candidates: *async_mqtt from Takatoshi Kondo (https://github.com/redboltz/async_mqtt) *multi from Alfredo Correa (https://gitlab.com/correaa/boost-multi) There's another MQTT library in the works proposed on Nov 2023, Async.MQTT5 from Ivica Siladic, Bruno Iljazovic and Korina Simicevic ( https://github.com/mireo/async-mqtt5) There were a total of three messages from the @Boost_Libraries X (formerly Twitter) account, all submitted by C++ Alliance team members. One of them featured artwork from Bob Ostrom, commissioned by us. Posts with visuals are three times more engaging than those with just text. We see the X platform as a vital tool for educating newer generations about the benefits of Boost. A total of $526,000 was spent on Boost-related contributions, broken down thusly (and rounded to the nearest thousand): Staff Engineers Compensation $392,000 Website Software Development $111,000 Server Hosting $23,000 During Q2 2024 we employed a total of 13 individuals to contribute to Boost. Here is a high-level summary of accomplishments: Sam Darwin (Chief Technical Officer) - Summary: Sam Darwin led major projects, overseeing the integration of new features in the Boost infrastructure. He coordinated between teams, ensuring smooth transitions and high-quality deliverables. His leadership was pivotal in the development of the new Boost website and improvements to the mailing list system. - Link: Sam Darwin's Q2 Update <https://cppalliance.org/sam/2024/07/10/SamsQ2Update.html> Dmitry Arkhipov (Staff Engineer) - Summary: Dmitry Arkhipov focused on maintaining and enhancing Boost libraries. He implemented several bug fixes, optimized existing code, and contributed to the development of new libraries. Dmitry also played a significant role in the continuous integration and deployment processes. - Link: Dmitry Arkhipov's Q2 Update <https://cppalliance.org/dmitry/2024/07/12/dmitrys-q2-update.html> Alan de Freitas (Staff Engineer) - Summary: Alan de Freitas worked extensively on the Boost website redesign, particularly on the back-end systems that support user-generated content and GitHub integration. He also contributed to developing new libraries and maintaining existing ones. - Link: Alan de Freitas's Q2 Update <https://cppalliance.org/alan/2024/07/13/AlanQ2Update.html> Christian Mazakas (Staff Engineer) - Summary: Christian Mazakas worked on enhancing Boost’s infrastructure, including optimizing server performance and improving deployment scripts. His contributions were crucial for maintaining the stability and efficiency of the Boost libraries. - Link: Not provided. Krystian Stasiowski (Staff Engineer) - Summary: Krystian Stasiowski focused on developing new features for existing Boost libraries and worked on performance optimizations. His work included contributing to the ongoing development of new libraries and providing technical support to other Boost authors. - Link: Krystian Stasiowski's Q2 Update <https://cppalliance.org/krystian/2024/07/15/KrystiansQ2Update.html> Peter Turcan (Senior Technical Writer) - Summary: Peter Turcan was responsible for creating and updating documentation for Boost libraries. He ensured that all new features and libraries were well-documented, making it easier for users to understand and utilize Boost’s capabilities. - Link: Peter Turcan's Q2 Update <https://cppalliance.org/peter/2024/07/07/PeterTurcan-Q2-2024.html> Matt Borland (Staff Engineer) - Summary: Matt Borland contributed to the development of new libraries and enhancements to existing ones. His focus was on improving library performance and ensuring that the codebase remained robust and reliable. - Link: Matt Borland's Q2 Update <https://cppalliance.org/matt/2024/07/08/Matts2024Q2Update.html> Ruben Perez (Staff Engineer) - Summary: Ruben Perez worked on several infrastructure projects, including server maintenance and optimization. He also contributed to the development and maintenance of Boost libraries, focusing on performance improvements and bug fixes. - Link: Ruben Perez's Q2 Update <https://cppalliance.org/q2_update/2024/07/09/RubenQ2.html> Mohammad Nejati (Staff Engineer) - Summary: Mohammad Nejati was involved in developing new libraries and improving existing ones. He focused on optimizing code and ensuring that Boost libraries were efficient and reliable. His work also included providing technical support to other developers. - Link: Mohammad Nejati's Q2 Update <https://cppalliance.org/mohammad/2024/07/10/MohammadsQ2Update.html> Fernando Pelliccioni (Staff Engineer) - Summary: Fernando Pelliccioni contributed to the ongoing development of the Boost libraries, focusing on implementing new features and optimizing performance. His work was instrumental in ensuring the high quality and reliability of Boost libraries. - Link: Fernando Pelliccioni's Q2 Update <https://cppalliance.org/fernando/2024/07/08/FernandoQ2Update.html> Joaquin M Lopez Munoz (Staff Engineer) - Summary: Joaquin M Lopez Munoz worked on several key projects, including the development of new Boost libraries and enhancements to existing ones. His contributions focused on improving code efficiency and performance. - Link: Joaquin M Lopez Munoz's Q2 Update <https://cppalliance.org/joaquin/2024/07/06/Joaquins2024Q2Update.html> Kenneth Reitz (Staff Engineer) - Summary: Kenneth Reitz focused on developing and maintaining Boost libraries, implementing new features, and optimizing existing code. His work also involved providing technical support and contributing to the Boost website redesign. - Link: Kenneth Reitz's Q2 Update <https://cppalliance.org/kenneth/2024/07/12/KennethQ2Update.html> Braden Ganetsky (Junior Staff Engineer) - Summary: Braden Ganetsky, as a junior engineer, contributed to various Boost library projects. His work included implementing new features, fixing bugs, and assisting with infrastructure maintenance. Braden’s contributions were valuable in supporting the overall development efforts. - Link: Braden Ganetsky's Q2 Update <https://cppalliance.org/braden/2024/07/14/BradenQ2Update.html>

6 8

Modular Boost status..
by René Ferdinand Rivera Morell 21 Jul '24

21 Jul '24

Yesterday I created PRs for each library that introduces the changes to build (and some code) to implement the modular B2 building. I track all the PRs here: <https://github.com/users/grafikrobot/projects/1/views/2> All the library PRs are in Draft status, as we wait for the tool related PRs to get merged. You can read an explanation of the changes here <https://github.com/grafikrobot/boost-b2-modular/blob/b2-modular/README.adoc> (the explanations may differ slightly from current reality). IMPORTANT: The PRs are all "Draft" as I continue to monitor build errors from any CI errors in the PRs. And to address feedback from authors. After the current release the process will go something like this: * I fix any current fallout in draft PRs. * The 1.86 release happens. * The owners merge the tool PRs to develop and master. * I fix any fallout from that. * Authors, and owners, merge library PRs to develop and master. * I fix any fallout from that. * I create subsequent PRs for the global B2 Boost build infrastructure to remove the old non-modular dead code. * The 1.87 release happens. Questions? -- -- René Ferdinand Rivera Morell -- Don't Assume Anything -- No Supone Nada -- Robot Dreams - http://robot-dreams.net

1 0

[compute] Maintenance status
by Joaquin M López Muñoz 21 Jul '24

21 Jul '24

It was brought to my attention that Boost.Compute seems to be all but abandoned: no updates in three years, more than 100 issues filed, 27 unattended PRs. This is a shame given that the library looks pretty popular based on GH stars and references on Internet. Are there volunteers to take on maintenance of the library? Best, Joaquin M Lopez Munoz

1 0

Should include of quadmath.h in multiprecision/cpp_bin_float.hpp be guarded with ifdef BOOST_MATH_HAS_QUADMATH_H?
by Martin Jambor 19 Jul '24

19 Jul '24

Hello, because of a bug[1] in GCC 13 and earlier versions, the #include of quadmath.h in multiprecision/cpp_bin_float.hpp did not fail even when the header file was not present on the system and compilation succeeded as long as nothing from the header file was actually needed. The bug has been fixed in GCC 14 which all of a sudden leads to new build requirements and failures such as [2]. Examining this build failure, I noticed that in math/special_functions/fpclassify.hpp (which is indirectly included from multiprecision/cpp_bin_float.hpp) the existence of the header file is specifically tested and macro BOOST_MATH_HAS_QUADMATH_H is defined or not accordingly. So I wanted to ask the question in the $subject. Could, or perhaps even should the include (together with its uses introduced in commit 4911125248bd) be guarded also by BOOST_MATH_HAS_QUADMATH_H and not just by BOOST_HAS_FLOAT128? Thank you, Martin [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80753 [2] https://bugzilla.opensuse.org/show_bug.cgi?id=1225861#c7

2 1

Boost Foundation, Boost, and the Beman Project
by Peter Dimov 19 Jul '24

19 Jul '24

Hi all, I recently brought up (by e-mail) the subject of the relationship between the Boost Foundation and the Beman Project before the BF board. I expressed the opinion that, since the Boost Foundation's primary purpose is to support Boost, the Beman Project should eventually have its own backing entity (foundation/nonprofit), instead of the existing Boost Foundation supporting both. David Sankel responded, quoted Boost Foundation's mission statement: "The Boost Foundation’s broad C++ mission is: (a) development of high quality, expert reviewed, legally unencumbered, open-source libraries, (b) inspiring standard enhancements, and (c) advancing and disseminating software development best practices. It does this by fostering community engagement, nurturing leaders, providing necessary financial/legal support, and making directional decisions in the event of Boost community deadlock." and helpfully pointed out that it very much doesn't say that supporting Boost is the primary purpose of the Foundation. And indeed, if one pays attention to the above, one would notice that Boost only appears once, at the end, somewhat incidentally, and as an afterthought. Unsurprisingly, I disagree. I think that the primary purpose of an entity named "the Boost Foundation" should be to support Boost, and if it currently isn't, something not quite right. At the moment I'm not proposing anything yet; this is purely informative. But no matter how I look at it, I see a pretty fundamental difference of opinion, which we'll need to deal with at some point.

12 32

Re: [boost] Boost Digest, Vol 7285, Issue 2
by Adam Getchell 19 Jul '24

19 Jul '24

> Date: Wed, 17 Jul 2024 13:38:58 -0700 > From: Vinnie Falco <vinnie.falco(a)gmail.com> > To: boost(a)lists.boost.org > Cc: Robert Ramey <ramey(a)rrsd.com> > Subject: Re: [boost] New Logo Discussion > Message-ID: > <CA+EzHGfmxMdhD04BCYz4Rvzk663KejBa+8QDF1fX84ZW1A3Ytg(a)mail.gmail.com> > Content-Type: text/plain; charset="UTF-8" > > On Wed, Jul 17, 2024 at 12:42?PM Robert Ramey via Boost < > boost(a)lists.boost.org> wrote: > >> FWIW - I much prefer the current logo which was developed by community >> inclusive process with many submissions and designs. >> > > Thanks. Upon reviewing my initial post I think I could have communicated > more clearly. Will everyone please vote on one of the following two options: > > 1. Boost adopts the proposed new logo with Alliance as custodian of the > trademark > > 2. No change I’m not sure I’m a voting member, but I like the new logo. Thanks also for doing all the legal review stuff. -- Adam Getchell https://adamgetchell.org <https://adamgetchell.org/>

2 1

Re: [boost] New Logo Discussion
by Joel de Guzman 18 Jul '24

18 Jul '24

On 7/18/24 9:36 AM, René Ferdinand Rivera Morell wrote: > On Wed, Jul 17, 2024 at 6:50 PM Joel de Guzman via Boost > <boost(a)lists.boost.org> wrote: >> On 7/18/24 3:49 AM, René Ferdinand Rivera Morell via Boost wrote: >>> On Wed, Jul 17, 2024 at 2:42 PM Robert Ramey via Boost >>> <boost(a)lists.boost.org> wrote: >>>> On 7/17/24 11:59 AM, Vinnie Falco via Boost wrote: >>>>> Hi. It is CppCon 2024 season, and the C++ Alliance is working on letting >>>>> people know all the new and exciting things happening in Boost. We're doing >>>>> this with Boost labeled conference shirts, and a beautiful brochure. You >>>>> can see a draft of this promotional piece here (note: work in progress): >>>>> >>>>> https://cppalliance.org/pdf/Boost-Brochure-CppCon-2024.pdf >>>>> >>>> FWIW - I much prefer the current logo which was developed by community >>>> inclusive process with many submissions and designs. >>> It wasn't. The logo picked by the community in that process was never >>> used. What is currently used was the result of private design between >>> the Boost Steering Committee and the artist that "won" that logo >>> contest. >> That is not correct. I was one of the major proponents of that logo contest (if not >> spearheded it). >> And I am not a member of the Boost Steering Committee. That contest was public and was >> discussed in the Boost list. It is NOT a private design. >> >> Here's part of the discussion (I do not have time to search all): >> https://lists.boost.org/Archives/boost//2005/03/81416.php >> >> You can see clearly I was asking for votes. > I did not claim the logo contest was not community driven and resulted > in a community choice. I would know, as I submitted 11 designs in that > context. What I claimed is that the **current** logo was not chosen by > a community process. As the **current** logo was NOT the winning logo. > The winning logo (actually four) was a single, or trio, of stacked > cards (see attached). And as you can see it is very different from > what we have now. I am confused. The winning logo is the beehive design by Zoltan Juhasz https://en.m.wikipedia.org/wiki/File:Boost.png I should know, I tallied the votes. I have no idea what that design you attached is. Regards, -- Joel de Guzman Cycfi Research, Inc.

3 3

Re: [boost] New Logo Discussion
by René Ferdinand Rivera Morell 18 Jul '24

18 Jul '24

On Wed, Jul 17, 2024 at 8:36 PM René Ferdinand Rivera Morell <grafikrobot(a)gmail.com> wrote: > > On Wed, Jul 17, 2024 at 6:50 PM Joel de Guzman via Boost > <boost(a)lists.boost.org> wrote: > > > > On 7/18/24 3:49 AM, René Ferdinand Rivera Morell via Boost wrote: > > > On Wed, Jul 17, 2024 at 2:42 PM Robert Ramey via Boost > > > <boost(a)lists.boost.org> wrote: > > >> On 7/17/24 11:59 AM, Vinnie Falco via Boost wrote: > > >>> Hi. It is CppCon 2024 season, and the C++ Alliance is working on letting > > >>> people know all the new and exciting things happening in Boost. We're doing > > >>> this with Boost labeled conference shirts, and a beautiful brochure. You > > >>> can see a draft of this promotional piece here (note: work in progress): > > >>> > > >>> https://cppalliance.org/pdf/Boost-Brochure-CppCon-2024.pdf > > >>> > > >> FWIW - I much prefer the current logo which was developed by community > > >> inclusive process with many submissions and designs. > > > It wasn't. The logo picked by the community in that process was never > > > used. What is currently used was the result of private design between > > > the Boost Steering Committee and the artist that "won" that logo > > > contest. > > > That is not correct. I was one of the major proponents of that logo contest (if not > > spearheded it). > > And I am not a member of the Boost Steering Committee. That contest was public and was > > discussed in the Boost list. It is NOT a private design. > > > > Here's part of the discussion (I do not have time to search all): > > https://lists.boost.org/Archives/boost//2005/03/81416.php > > > > You can see clearly I was asking for votes. > > I did not claim the logo contest was not community driven and resulted > in a community choice. I would know, as I submitted 11 designs in that > context. What I claimed is that the **current** logo was not chosen by > a community process. As the **current** logo was NOT the winning logo. > The winning logo (actually four) was a single, or trio, of stacked > cards (see attached). And as you can see it is very different from > what we have now. Trying this again because the attachment was too big. :-( See pair of individual images. -- -- René Ferdinand Rivera Morell -- Don't Assume Anything -- No Supone Nada -- Robot Dreams - http://robot-dreams.net

1 0

Where is Boost.Parser?
by Vinnie Falco 17 Jul '24

17 Jul '24

Boost.Parser was accepted on February 28th but it is not in the superproject, and the last commit in the source repository is from four months ago. I am developing a Boost brochure for CppCon 2024 and I'd like to go to press with Boost.Parser as a listed library, so this is a blocker. Thanks

3 5

Rephrased: Building Boost for MacOS / clang
by Stephen Greenfield 17 Jul '24

17 Jul '24

On Thu, 11 Jul 2024 Richard Hodges wrote: > This usually happens because you're compiling with one standard library > (e.g. libc++, the default on clang) while your boost libraries were > compiled with another (e.g. libstdc++, the default on gcc). I've recompiled my MacOS program for GCC (GNU C++17) and linked with libstdc++ to be compatible with the default build of Boost. Your suggestion WAS the solution to my reported slew of error messages. Thanks! QUESTION 1: But for building a standard MacOS or iPhone/iPad app, shouldn't I be building both my app and Boost for clang, so I can link with libc++? When I looked at the list of toolsets in the "getting started with unix variants", included with the 1_85_0 .zip package, there was no listing for toolset=clang or toolset=clang-darwin. Nor is there any mention of clang on: https://www.boost.org/doc/libs/1_85_0/more/getting_started/unix-variants.ht… QUESTION 2: So what is the proper toolset / build instructions to build for MacOS using the clang C++17 compiler? Stephen

1 0

A question for folks here
by David Sankel 16 Jul '24

16 Jul '24

For those who got involved in Boost within the last couple years, how did you hear about boost? What attracted you to it? For those who have been around for a while, what keeps you here? Why do you stay engaged?

16 25

[unordered] New natvis visualizations + accompanying article
by Braden Ganetsky 16 Jul '24

16 Jul '24

Hi everyone, This is my first message on the ML. I've written visualizations in the Visual Studio Natvis framework for the Boost.Unordered containers and iterators. This will improve the user experience for anyone using Visual Studio. The visualizations mirror those of the STL unordered containers as closely as possible, except that end iterators display as "{ end iterator }" instead of the visualization just breaking. Here is the file: https://github.com/boostorg/unordered/blob/develop/extra/boost_unordered.na… I've written an accompanying article about the natvis implementation for the closed-addressing containers. I will be writing a second article about the implementation for the open-addressing containers. This first article contains some tips and tricks for using the natvis framework that I wish I knew before going into this, especially about using "<Intrinsic>" elements. Hopefully it can help someone else. Link to the article: https://blog.ganets.ky/NatvisForUnordered/ Custom gdb pretty-printers will be next up. Thank you to Joaquín for reviewing the code and the article. Thanks all, Braden Ganetsky

2 2

Re: [boost] Boost Digest, Vol 7279, Issue 2
by Stephen Greenfield 15 Jul '24

15 Jul '24

BUMP / RE-SENT -- I think I got lost in a flurry of responses to another subject: Richard – > This usually happens because you're compiling with one standard library > (e.g. libc++, the default on clang) while your boost libraries were > compiled with another (e.g. libstdc++, the default on gcc). That makes sense. Does my MacOS program need to be compiled for GCC (IE GNU C++17 / GNU C++20), and then linked with libstdc++ to be compatible with the default build of Boost, or the opposite: build Boost and link with libc++? I saw that there's a list of toolsets, but in the "getting started with unix variants", included with the 1_85_0 .zip package, there is no listing for toolset=clang or toolset=clang-darwin. Nor is there any mention of clang on: https://www.boost.org/doc/libs/1_85_0/more/getting_started/unix-variants.ht… Stephen

1 0

Re: [boost] Boost Digest, Vol 7279, Issue 2
by Stephen Greenfield 11 Jul '24

11 Jul '24

Richard – > This usually happens because you're compiling with one standard library > (e.g. libc++, the default on clang) while your boost libraries were > compiled with another (e.g. libstdc++, the default on gcc). That makes sense. Does my MacOS program need to be compiled for GCC (IE GNU C++17 / GNU C++20), and then linked with libstdc++ to be compatible with the default build of Boost, or the opposite: build Boost and link with libc++? I saw that there’s a list of toolsets, but in the “getting started with unix variants”, included with the 1_85_0 .zip package, there is no listing for toolset=clang or toolset=clang-darwin. Nor is there any mention of clang on: https://www.boost.org/doc/libs/1_85_0/more/getting_started/unix-variants.ht… Stephen -- ------------------------------ Message: 5 Date: Thu, 11 Jul 2024 09:43:01 +0200 From: Richard Hodges <hodges.r(a)gmail.com> To: boost(a)lists.boost.org Subject: Re: [boost] Updating from 1_71_0 to 1_85_0: "No member named 'memcpy' in namespace 'std::__1'" Message-ID: <CALvx3haD3uRR4sXjjDq5Hrw4XoTq11HMqQyq2D5taJQzH7ys7A(a)mail.gmail.com> Content-Type: text/plain; charset="UTF-8" This usually happens because you're compiling with one standard library (e.g. libc++, the default on clang) while your boost libraries were compiled with another (e.g. libstdc++, the default on gcc). R On Thu, 11 Jul 2024 at 02:21, Stephen Greenfield via Boost < boost(a)lists.boost.org> wrote: > Dear Boost gurus, > > Building on MacOS 12.7.3, Xcode 13.4.1, C++ dialect = C++17. Deployment > target is 10.15. This particular project is x86_64 architecture. I?m only > linking libboost_filesystem.a and libboost_iostreams.a (I show my build > boost build steps at the end). > > When updating from Boost 1_71_0 to 1_85_0, I?m suddenly encountering these > kinds of errors: > > > /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.3.sdk/usr/include/c++/v1/__functional/hash.h:40:5: > No member named 'memcpy' in namespace 'std::__1'; did you mean simply > 'memcpy'? > > > /Users/stephen/dev/Boost > Libraries/boost_1_85_0/boost/system/detail/append_int.hpp:23:5: No member > named 'snprintf' in namespace 'boost::system::detail'; did you mean simply > 'snprintf'? > > > > > In file included from > /Users/stephen/dev/Screenwriter/ScreenWriterX/ScreenWriterX/Screenwriter > Sources/Text Engine/CThingEdit.cp:22: > > In file included from ../ScreenWriterX/ScreenWriterX/Screenwriter > Sources/Text Engine/CThingEdit.h:61: > > In file included from > /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.3.sdk/usr/include/c++/v1/string:522: > > In file included from > /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.3.sdk/usr/include/c++/v1/algorithm:653: > > In file included from > /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.3.sdk/usr/include/c++/v1/functional:500: > > In file included from > /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.3.sdk/usr/include/c++/v1/__functional/function.h:20: > > In file included from > /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.3.sdk/usr/include/c++/v1/__memory/shared_ptr.h:25: > > In file included from > /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.3.sdk/usr/include/c++/v1/__memory/unique_ptr.h:15: > > /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.3.sdk/usr/include/c++/v1/__functional/hash.h:40:5: > error: no member named 'memcpy' in namespace 'std::__1'; did you mean > simply 'memcpy'? > > _VSTD::memcpy(&__r, __p, sizeof(__r)); > > ^~~~~~~ > > In file included from <built-in>:1: > > In file included from > /Users/stephen/dev/Screenwriter/ScreenWriterX/ScreenWriterX/Screenwriter > Sources/Screenwriter_Prefix.pch:505: > > In file included from > /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.3.sdk/usr/include/MacTypes.h:44: > > In file included from > /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.3.sdk/usr/include/c++/v1/stdbool.h:22: > > /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.3.sdk/usr/include/c++/v1/__config:858:15: > note: expanded from macro '_VSTD' > > #define _VSTD std::_LIBCPP_ABI_NAMESPACE > > ^ > > In file included from > /Users/stephen/dev/Screenwriter/ScreenWriterX/ScreenWriterX/Screenwriter > Sources/Text Engine/CThingEdit.cp:22: > > In file included from ../ScreenWriterX/ScreenWriterX/Screenwriter > Sources/Text Engine/CThingEdit.h:61: > > In file included from > /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.3.sdk/usr/include/c++/v1/string:522: > > In file included from > /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.3.sdk/usr/include/c++/v1/algorithm:652: > > /Users/stephen/dev/Boost > Libraries/boost_1_85_0/boost/compatibility/cpp_c_headers/cstring:22:11: > note: 'memcpy' declared here > > using ::memcpy; > > ^ > ?this is for all sorts of symbols. ALSO: > > > > > Showing All Errors Only > > /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.3.sdk/usr/include/c++/v1/filesystem:2635:5: > Use of undeclared identifier '_LIBCPP_UNREACHABLE' > > > When including: > > #include <fstream> > > > The libraries were build using: > > ./bootstrap.sh cxxflags="-arch x86_64 -arch arm64" cflags="-arch x86_64 > -arch arm64" linkflags="-arch x86_64 -arch arm64" > > ./b2 toolset=clang-darwin target-os=darwin architecture=arm abi=aapcs > cxxflags="-arch arm64" cflags="-arch arm64" linkflags="-arch arm64" -a > > mkdir -p arm64 && cp stage/lib/*.* arm64 > > ./b2 toolset=clang-darwin target-os=darwin architecture=x86 > cxxflags="-arch x86_64" cflags="-arch x86_64" linkflags="-arch x86_64" > abi=sysv binary-format=mach-o -a > > mkdir x86_64 && cp stage/lib/*.* x86_64 > > The intention was for me to eventually make UNIVERSAL dylibs using lipo ? > but for now, I just want to get my build back to functioning with Boost > 1_85_0. > > NOTE that I?m continuing to use Boost?s Filesystem ? even though I THINK > Xcode?s C++20 might now support std::filesystem. > > I?ve searched all over for the answer ? even consulted ChatGPT ? but > haven?t found a solution. But this seems like something bone-headed I?ve > missed. > > Stephen > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost > ------------------------------ Subject: Digest Footer _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost ------------------------------ End of Boost Digest, Vol 7279, Issue 2 **************************************

1 0

Updating from 1_71_0 to 1_85_0: "No member named 'memcpy' in namespace 'std::__1'"
by Stephen Greenfield 11 Jul '24

11 Jul '24

Dear Boost gurus, Building on MacOS 12.7.3, Xcode 13.4.1, C++ dialect = C++17. Deployment target is 10.15. This particular project is x86_64 architecture. I’m only linking libboost_filesystem.a and libboost_iostreams.a (I show my build boost build steps at the end). When updating from Boost 1_71_0 to 1_85_0, I’m suddenly encountering these kinds of errors: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.3.sdk/usr/include/c++/v1/__functional/hash.h:40:5: No member named 'memcpy' in namespace 'std::__1'; did you mean simply 'memcpy'? /Users/stephen/dev/Boost Libraries/boost_1_85_0/boost/system/detail/append_int.hpp:23:5: No member named 'snprintf' in namespace 'boost::system::detail'; did you mean simply 'snprintf'? In file included from /Users/stephen/dev/Screenwriter/ScreenWriterX/ScreenWriterX/Screenwriter Sources/Text Engine/CThingEdit.cp:22: In file included from ../ScreenWriterX/ScreenWriterX/Screenwriter Sources/Text Engine/CThingEdit.h:61: In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.3.sdk/usr/include/c++/v1/string:522: In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.3.sdk/usr/include/c++/v1/algorithm:653: In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.3.sdk/usr/include/c++/v1/functional:500: In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.3.sdk/usr/include/c++/v1/__functional/function.h:20: In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.3.sdk/usr/include/c++/v1/__memory/shared_ptr.h:25: In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.3.sdk/usr/include/c++/v1/__memory/unique_ptr.h:15: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.3.sdk/usr/include/c++/v1/__functional/hash.h:40:5: error: no member named 'memcpy' in namespace 'std::__1'; did you mean simply 'memcpy'? _VSTD::memcpy(&__r, __p, sizeof(__r)); ^~~~~~~ In file included from <built-in>:1: In file included from /Users/stephen/dev/Screenwriter/ScreenWriterX/ScreenWriterX/Screenwriter Sources/Screenwriter_Prefix.pch:505: In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.3.sdk/usr/include/MacTypes.h:44: In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.3.sdk/usr/include/c++/v1/stdbool.h:22: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.3.sdk/usr/include/c++/v1/__config:858:15: note: expanded from macro '_VSTD' #define _VSTD std::_LIBCPP_ABI_NAMESPACE ^ In file included from /Users/stephen/dev/Screenwriter/ScreenWriterX/ScreenWriterX/Screenwriter Sources/Text Engine/CThingEdit.cp:22: In file included from ../ScreenWriterX/ScreenWriterX/Screenwriter Sources/Text Engine/CThingEdit.h:61: In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.3.sdk/usr/include/c++/v1/string:522: In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.3.sdk/usr/include/c++/v1/algorithm:652: /Users/stephen/dev/Boost Libraries/boost_1_85_0/boost/compatibility/cpp_c_headers/cstring:22:11: note: 'memcpy' declared here using ::memcpy; ^ …this is for all sorts of symbols. ALSO: Showing All Errors Only /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.3.sdk/usr/include/c++/v1/filesystem:2635:5: Use of undeclared identifier '_LIBCPP_UNREACHABLE' When including: #include <fstream> The libraries were build using: ./bootstrap.sh cxxflags="-arch x86_64 -arch arm64" cflags="-arch x86_64 -arch arm64" linkflags="-arch x86_64 -arch arm64" ./b2 toolset=clang-darwin target-os=darwin architecture=arm abi=aapcs cxxflags="-arch arm64" cflags="-arch arm64" linkflags="-arch arm64" -a mkdir -p arm64 && cp stage/lib/*.* arm64 ./b2 toolset=clang-darwin target-os=darwin architecture=x86 cxxflags="-arch x86_64" cflags="-arch x86_64" linkflags="-arch x86_64" abi=sysv binary-format=mach-o -a mkdir x86_64 && cp stage/lib/*.* x86_64 The intention was for me to eventually make UNIVERSAL dylibs using lipo – but for now, I just want to get my build back to functioning with Boost 1_85_0. NOTE that I’m continuing to use Boost’s Filesystem – even though I THINK Xcode’s C++20 might now support std::filesystem. I’ve searched all over for the answer – even consulted ChatGPT – but haven’t found a solution. But this seems like something bone-headed I’ve missed. Stephen

4 3

Re: [boost] A question for folks here
by me＠kennethreitz.org 11 Jul '24

11 Jul '24

Hi all, My name is Kenneth Reitz, and I got involved with Boost when Vinnie Falco asked me to join the C++ Alliance to work on the new boost website. You might recognize my name from the Python community, where I’m known for making Requests, Pipenv, and other tools. It’s nice to meet everyone! — Kenneth Reitz > 1. A question for folks here (David Sankel) > 2. Re: A secure string library? (Andrey Semashev) > 3. Re: A secure string library? (Andrey Semashev) > 4. Re: A question for folks here (Richard Hodges) > 5. Re: A secure string library? (Daniela Engert) > 6. Re: A secure string library? (Andrey Semashev) > 7. Re: A secure string library? (Christian Mazakas) > 8. Re: A question for folks here (Matt Borland) > 9. Re: A question for folks here (Christopher Kormanyos) > 10. Re: A question for folks here (Louis Tatta) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 10 Jul 2024 10:47:50 -0400 > From: David Sankel <camior(a)gmail.com> > To: Boost <boost(a)lists.boost.org> > Subject: [boost] A question for folks here > Message-ID: > <CAFYdOO+m95fKjxnKY3SY_eHC-X=PLs12BteaONG+QpS6fTCxcQ(a)mail.gmail.com> > Content-Type: text/plain; charset="UTF-8" > > For those who got involved in Boost within the last couple years, how did > you hear about boost? What attracted you to it? > > For those who have been around for a while, what keeps you here? Why do you > stay engaged? > > > ------------------------------ > > Message: 2 > Date: Wed, 10 Jul 2024 18:26:20 +0300 > From: Andrey Semashev <andrey.semashev(a)gmail.com> > To: boost(a)lists.boost.org > Subject: Re: [boost] A secure string library? > Message-ID: <6265cabd-c0b9-405e-98f4-8a47683e5472(a)gmail.com> > Content-Type: text/plain; charset=UTF-8 > > On 7/10/24 14:59, Peter Dimov via Boost wrote: >> Ruben Perez wrote: >>> There is OPENSSL_Cleanse, which does a similar job. I found it surprisingly >>> simple - I wonder if this is just enough or there are any corner cases where this >>> doesn't work: >>> https://github.com/openssl/openssl/blob/b544047c99c4a7413f793afe82ab1c165f8… >> >> That's an interesting approach. I can't offhand think of a reason why it wouldn't >> work. > > The compiler might convert OPENSSL_cleanse to something like this: > > void OPENSSL_cleanse(void *ptr, size_t len) > { > memset_t func = memset_func; > if (func != memset) > func(ptr, 0, len); > else > memset(ptr, 0, len); > } > > The purpose here is that, if memset_func is actually memset most of the > time, it can further optimize the call to memset, including to > completely remove it, depending on the call context. The > (well-predictable) branch is typically cheaper than an indirect call. I > think I've seen compilers do something along those lines as a result of > call devirtualization, especially with IPO and LTCG. > > I'm not saying that's what actually happens in OpenSSL, just that > something like this is possible. I think, a dummy asm statement is more > reliable and more efficient. > > void secure_cleanse(void *ptr, size_t len) > { > memset(ptr, 0, len); // a normal memset, optimizations are welcome > __asm__ __volatile__ ("" : : "r" (ptr), "r" (len) : "memory"); > } > > You can even make that function inline and it'll work, and in an optimal > way, too. > > > > ------------------------------ > > Message: 3 > Date: Wed, 10 Jul 2024 18:37:00 +0300 > From: Andrey Semashev <andrey.semashev(a)gmail.com> > To: boost(a)lists.boost.org > Subject: Re: [boost] A secure string library? > Message-ID: <57326885-13ab-4a73-ac5a-5aa6357e799c(a)gmail.com> > Content-Type: text/plain; charset=UTF-8 > > On 7/10/24 18:26, Andrey Semashev wrote: >> On 7/10/24 14:59, Peter Dimov via Boost wrote: >>> Ruben Perez wrote: >>>> There is OPENSSL_Cleanse, which does a similar job. I found it surprisingly >>>> simple - I wonder if this is just enough or there are any corner cases where this >>>> doesn't work: >>>> https://github.com/openssl/openssl/blob/b544047c99c4a7413f793afe82ab1c165f8… >>> >>> That's an interesting approach. I can't offhand think of a reason why it wouldn't >>> work. >> >> The compiler might convert OPENSSL_cleanse to something like this: >> >> void OPENSSL_cleanse(void *ptr, size_t len) >> { >> memset_t func = memset_func; >> if (func != memset) >> func(ptr, 0, len); >> else >> memset(ptr, 0, len); >> } >> >> The purpose here is that, if memset_func is actually memset most of the >> time, it can further optimize the call to memset, including to >> completely remove it, depending on the call context. The >> (well-predictable) branch is typically cheaper than an indirect call. I >> think I've seen compilers do something along those lines as a result of >> call devirtualization, especially with IPO and LTCG. >> >> I'm not saying that's what actually happens in OpenSSL, just that >> something like this is possible. I think, a dummy asm statement is more >> reliable and more efficient. >> >> void secure_cleanse(void *ptr, size_t len) >> { >> memset(ptr, 0, len); // a normal memset, optimizations are welcome >> __asm__ __volatile__ ("" : : "r" (ptr), "r" (len) : "memory"); >> } >> >> You can even make that function inline and it'll work, and in an optimal >> way, too. > > And for compilers that don't support __asm__, I think you could replace > it with: > > std::atomic_signal_fence(std::memory_order::acq_rel); > > > > ------------------------------ > > Message: 4 > Date: Wed, 10 Jul 2024 18:01:03 +0200 > From: Richard Hodges <hodges.r(a)gmail.com> > To: boost(a)lists.boost.org > Subject: Re: [boost] A question for folks here > Message-ID: > <CALvx3hYSO6svxz_aEw_LoaraweTguqW+jJScTyfymZAveOrXZg(a)mail.gmail.com> > Content-Type: text/plain; charset="UTF-8" > > On Wed, 10 Jul 2024 at 16:48, David Sankel via Boost <boost(a)lists.boost.org> > wrote: > >> For those who got involved in Boost within the last couple years, how did >> you hear about boost? What attracted you to it? >> > > I've been using boost as an essential force multiplier of C++ since version > 1.35 when Asio appeared, courtesy of Chris Kohlhoff. > > More recently in 2017, I needed an asynchronous websocket library for C++ > and lo-and-behold, boost had one, courtesy of Vinnie Falco. > > >> >> For those who have been around for a while, what keeps you here? Why do you >> stay engaged? >> > > After finishing a contract in which I used Boost.Beast et.al. in production > code, I took up an offer by the C++ Alliance to become a maintainer of it. > A bit of a "Victor Kiam" moment, if you will. > > While working for the C++ Alliance I was also involved in the design and > first cut of Boost.Json and had some input into Boost.Url, another two very > keenly needed libraries sponsored by the C++ Alliance. > I am no longer working for the C++ Alliance, but maintain a warm > relationship with the organisation. > > I am currently using Boost.Cobalt in a financial trading software suite. > > I stay engaged because: > - I don't want to have to switch languages - C++ is perfectly fine for me. > - Boost polyfills all the essential functionality that the children running > WG21 continue to refuse to provide. > - It's convenient to have one library that provides (almost) every tool I > need. > > My very great thanks to the original authors and contributors, and more > recently to the C++ Alliance, which as far as I can see is the only major > sponsor of Boost. > Without this organisation's involvement, I believe the libraries would have > been allowed to fall into disrepair a long time ago. > > I don't think I have met more than one team in the financial industry which > uses C++ but which does not use Boost. > > On a separate note, I was deeply disappointed by your recent public > outbursts, David. > > Sincerely, > > Richard Hodges > A C++phile > ex maintainer of Boost.Beast > contributor to Boost.Json, Boost.Url > Advisor to Boost.MySQL, Boost.Cobalt > > >> >> _______________________________________________ >> Unsubscribe & other changes: >> http://lists.boost.org/mailman/listinfo.cgi/boost >> > > > ------------------------------ > > Message: 5 > Date: Wed, 10 Jul 2024 18:13:41 +0200 > From: Daniela Engert <dani(a)ngrt.de> > To: boost(a)lists.boost.org > Subject: Re: [boost] A secure string library? > Message-ID: <98140e71-ef1e-431a-a089-e24f56e390bd(a)ngrt.de> > Content-Type: text/plain; charset=UTF-8; format=flowed > > Am 10.07.2024 um 17:37 schrieb Andrey Semashev via Boost: >> On 7/10/24 18:26, Andrey Semashev wrote: >>> On 7/10/24 14:59, Peter Dimov via Boost wrote: >>>> Ruben Perez wrote: >>>>> There is OPENSSL_Cleanse, which does a similar job. I found it surprisingly >>>>> simple - I wonder if this is just enough or there are any corner cases where this >>>>> doesn't work: >>>>> https://github.com/openssl/openssl/blob/b544047c99c4a7413f793afe82ab1c165f8… >>>> That's an interesting approach. I can't offhand think of a reason why it wouldn't >>>> work. >>> The compiler might convert OPENSSL_cleanse to something like this: >>> >>> void OPENSSL_cleanse(void *ptr, size_t len) >>> { >>> memset_t func = memset_func; >>> if (func != memset) >>> func(ptr, 0, len); >>> else >>> memset(ptr, 0, len); >>> } >>> >>> The purpose here is that, if memset_func is actually memset most of the >>> time, it can further optimize the call to memset, including to >>> completely remove it, depending on the call context. The >>> (well-predictable) branch is typically cheaper than an indirect call. I >>> think I've seen compilers do something along those lines as a result of >>> call devirtualization, especially with IPO and LTCG. >>> >>> I'm not saying that's what actually happens in OpenSSL, just that >>> something like this is possible. I think, a dummy asm statement is more >>> reliable and more efficient. >>> >>> void secure_cleanse(void *ptr, size_t len) >>> { >>> memset(ptr, 0, len); // a normal memset, optimizations are welcome >>> __asm__ __volatile__ ("" : : "r" (ptr), "r" (len) : "memory"); >>> } >>> >>> You can even make that function inline and it'll work, and in an optimal >>> way, too. >> And for compilers that don't support __asm__, I think you could replace >> it with: >> >> std::atomic_signal_fence(std::memory_order::acq_rel); >> > I think Peter is actually right in his assessment: > > While 'memset_func' is TU-local, it is also 'volatile'. This implies > every look at it might reveal a different content. Therefore the > necessity for non-constness and dynamic initialization. We humans see > that the variable can't change its value other than in the > initialization. The compiler can't reason that because said properties > are the only ones known during the compilation of 'OPENSSL_cleanse()'. > It can't perform unbounded look-ahead until the end of the TU like we do. > > Dani > > -- > PGP/GPG: 2CCB 3ECB 0954 5CD3 B0DB 6AA0 BA03 56A1 2C4638C5 > > ------------------------------ > > Message: 6 > Date: Wed, 10 Jul 2024 19:24:48 +0300 > From: Andrey Semashev <andrey.semashev(a)gmail.com> > To: boost(a)lists.boost.org > Subject: Re: [boost] A secure string library? > Message-ID: <905dd5f7-5d29-48ab-87aa-6aa0a23e60c6(a)gmail.com> > Content-Type: text/plain; charset=UTF-8 > > On 7/10/24 19:13, Daniela Engert via Boost wrote: >> Am 10.07.2024 um 17:37 schrieb Andrey Semashev via Boost: >>> On 7/10/24 18:26, Andrey Semashev wrote: >>>> On 7/10/24 14:59, Peter Dimov via Boost wrote: >>>>> Ruben Perez wrote: >>>>>> There is OPENSSL_Cleanse, which does a similar job. I found it >>>>>> surprisingly >>>>>> simple - I wonder if this is just enough or there are any corner >>>>>> cases where this >>>>>> doesn't work: >>>>>> https://github.com/openssl/openssl/blob/b544047c99c4a7413f793afe82ab1c165f8… >>>>> That's an interesting approach. I can't offhand think of a reason >>>>> why it wouldn't >>>>> work. >>>> The compiler might convert OPENSSL_cleanse to something like this: >>>> >>>> ?? void OPENSSL_cleanse(void *ptr, size_t len) >>>> ?? { >>>> ???? memset_t func = memset_func; >>>> ???? if (func != memset) >>>> ?????? func(ptr, 0, len); >>>> ???? else >>>> ?????? memset(ptr, 0, len); >>>> ?? } >>>> >>>> The purpose here is that, if memset_func is actually memset most of the >>>> time, it can further optimize the call to memset, including to >>>> completely remove it, depending on the call context. The >>>> (well-predictable) branch is typically cheaper than an indirect call. I >>>> think I've seen compilers do something along those lines as a result of >>>> call devirtualization, especially with IPO and LTCG. >>>> >>>> I'm not saying that's what actually happens in OpenSSL, just that >>>> something like this is possible. I think, a dummy asm statement is more >>>> reliable and more efficient. >>>> >>>> ?? void secure_cleanse(void *ptr, size_t len) >>>> ?? { >>>> ???? memset(ptr, 0, len); // a normal memset, optimizations are welcome >>>> ???? __asm__ __volatile__ ("" : : "r" (ptr), "r" (len) : "memory"); >>>> ?? } >>>> >>>> You can even make that function inline and it'll work, and in an optimal >>>> way, too. >>> And for compilers that don't support __asm__, I think you could replace >>> it with: >>> >>> ?? std::atomic_signal_fence(std::memory_order::acq_rel); >>> >> I think Peter is actually right in his assessment: >> >> While 'memset_func' is TU-local, it is also 'volatile'. This implies >> every look at it might reveal a different content. Therefore the >> necessity for non-constness and dynamic initialization. We humans see >> that the variable can't change its value other than in the >> initialization. The compiler can't reason that because said properties >> are the only ones known during the compilation of 'OPENSSL_cleanse()'. >> It can't perform unbounded look-ahead until the end of the TU like we do. > > With volatile, the compiler is not allowed to optimize away or reorder > loads and stores of the variable. There's no restriction on what the > compiler is allowed to do with the loaded value. > > > > ------------------------------ > > Message: 7 > Date: Wed, 10 Jul 2024 10:10:43 -0700 > From: Christian Mazakas <christian.mazakas(a)gmail.com> > To: boost(a)lists.boost.org > Subject: Re: [boost] A secure string library? > Message-ID: > <CAHf7xWueD5=ekMC178pikzH2iuhAtyzC6v5UgPBSoj0NMy3y9Q(a)mail.gmail.com> > Content-Type: text/plain; charset="UTF-8" > >> Andrey Semashev via Boost: >> With volatile, the compiler is not allowed to optimize away or reorder >> loads and stores of the variable. There's no restriction on what the >> compiler is allowed to do with the loaded value. > > It could insert a branch against `memset` but that seems really only like a > theoretical > optimization. > > This is an example where the volatile preserves the secure_erase() call: > https://godbolt.org/z/854jfarb9 > > Kind of neat trying to get the compiler to elide this stuff. You were > right, Andrey, you really need > LTO and LTCG and the like to get this kind of behavior. Super neat stuff. > > Idk, seems like whatever OpenSSL is doing is Sound Enough in practice. > > I'd be curious to know if it's actually sound for a compiler to make that > kind of optimization or at least > what are the limits on how far a compiler can actually go to ensure > soundness. If you know those limits, > you can probably make this pattern work reliably. > > - Christian > > > ------------------------------ > > Message: 8 > Date: Wed, 10 Jul 2024 17:57:57 +0000 > From: Matt Borland <matt(a)mattborland.com> > To: boost(a)lists.boost.org > Subject: Re: [boost] A question for folks here > Message-ID: > <LQ-gmVceAUPyCRzsmP5gN1Z4NJiwrRtJ-yJY5Q6Ne-3SnJ_omC84hltKP9AbS3x-TVlz35Amln3jW0CBdG0nnzAioM53fxXobq0GO3zYb2E=(a)mattborland.com> > > Content-Type: text/plain; charset="utf-8" > > >> For those who got involved in Boost within the last couple years, how did >> you hear about boost? > > I heard about it from a university professor as a freshman undergraduate student in 2011. Since C++11 was just coming about, and the speed of updating toolchains in academia is slow so we were stuck in the C++03 days on old RHEL systems. > >> What attracted you to it? > > I was studying aeronautical engineering so having pre-made libraries like Boost.Math, Boost.Multiprecision, and ODEint were useful to me. I could focus on the problem at hand rather than having to roll my own special functions, solvers, big numbers, constants, etc. > >> For those who have been around for a while, what keeps you here? Why do you stay engaged? > > I started to get involved with development during the COVID lockdowns because like many people I found myself with quite a bit of extra free time. What hooked me was learning from and working with extremely competent programmers and mathematicians like John Maddock, Chris Kormanyos, and Nick Thompson. I was hired by the C++ Alliance at the beginning of 2023 and they have sponsored my development since. This allows me to work on new (https://github.com/cppalliance/decimal) and existing libraries (charconv, math, multiprecision, random, etc) in a way that I was never able to on a volunteer basis with a full time job. The community is large, knowledgeable, and helpful so I continue to enjoy working on Boost. > > > I think it would be beneficial to the developer community for the Boost Foundation board members to also answer these questions. Frankly some even require introductions with their answers. There are members of the board like Peter, Glen, and Zach that are Titans of Boost, and those like Kristen who I had not heard of until her post about wanting to cut ties with the C++ Alliance. Having unknown members of the Boost Foundation runs counter to their mission statement whereby the board intends to achieve its mission by "fostering community engagement, [and] nurturing leaders..."[1]. > > Matt > > [1] https://sites.google.com/boost.org/boost-foundation/home >

2 1

A secure string library?
by Ruben Perez 10 Jul '24

10 Jul '24

Hi all, Boost.MySQL and Boost.Redis need to hold sensitive information, like passwords, to work. Using std::string may be sufficient for many use cases, but it's not the best security practice. std::string doesn't wipe its memory on cleanup, resulting in the password remaining in memory for an indeterminate amount of time. Other languages like C# implement a SecureString class that wipes memory on destruction. Crypto++ implements a similar concept, but it's a big dependency I'm not willing to take. I'd like to know whether everyone else's opinion on this: * Have you faced this issue before? * Do you think this is something we (as Boost authors) should care about, or am I thinking too much? * Do you think a library implementing secure string/array/buffer classes would be a valuable addition to Boost? Thanks, Ruben.

11 22

[boost 1.85.0 MSVC142-64 ]type_name.hpp(354,2): error C2766: explicit specialization; 'boost::core::detail::tn_holder<unsigned short>' has already been defined
by Bhuyan, Jyotideep 10 Jul '24

10 Jul '24

Hello, I am updating my code from boost version 1.78 to boost 1.85. and facing build issues "error C2766: explicit specialization; 'boost::core::detail::tn_holder<unsigned short>' has already been defined" Below is the error that I am facing that needs your help. I could not find any code or direct header file inclusion in my code related to the below error. C:\<my boost>\boost_1_85\boost\boost\core\type_name.hpp(354,2): error C2766: explicit specialization; 'boost::core::detail::tn_holder<unsigned short>' has already been defined. C:\<my boost>\boost_1_85\boost\boost\core\type_name.hpp(273): message : see previous definition of 'tn_holder<unsigned short> Please note that after upgrading to boost 1.85, the compiler was not able to find "#include <boost/function/detail/prologue.hpp>", I checked this file is not present in the new version. Hence, I have commented header file inclusion in my code. I am building the code for MSVC142 (C++14) for 64-bit Windows 10 architecture. 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 2

failure to produce PDF documentation
by Robert Ramey 10 Jul '24

10 Jul '24

For many years, I've been using the xslt based system for converting boostbook xml into html an pdf files. Once I got it set up, I've never had a problem. But now, it is failing with some error messages provoked by the contents of some xml files which are part of boost book. A casual review of the correspondng github repository shows the that the some of these files have been "maintained" recently ... some as recently as 3 days ago. Could someone (probably the maintainer) look into this. I noticed that when I try to appy this to the safe numerics library. The following should reproduce the problem: cd /Users/robertramey/WorkingProjects/modular-boost/libs/safe_numerics/doc/boostbook $ls *.sh makeepub.sh makehtml.sh makepdf.sh makeproposal.sh $echo $PATH /Volumes/public/fop-2.1:.:/Volumes/public/menu_bash:/usr/local/bin:/System/Cryptexes/App/usr/bin:/usr/bin:/bin:/usr/sbin:/sbin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/local/bin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/bin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/appleinternal/bin:/Library/Apple/usr/bin $./makepdf.sh [Fatal Error] docbook.xsl:6:3: The element type "hr" must be terminated by the matching end-tag "</hr>". http://docbook.sourceforge.net/release/xsl/current/fo/docbook.xsl; Line #6; Column #3; org.xml.sax.SAXParseException; systemId: http://docbook.sourceforge.net/release/xsl/current/fo/docbook.xsl; lineNumber: 6; columnNumber: 3; The element type "hr" must be terminated by the matching end-tag "</hr>". Jul 09, 2024 2:58:38 PM org.apache.fop.cli.Main startFOP SEVERE: Exception ... Thanks to whoever looks into this. Robert Ramey

2 3

Boost 1.85, Windows, VS2022 17.10.3, build does not create any libs on building boost
by Dennis Luehring 09 Jul '24

09 Jul '24

my system Windows 10 x64, VS2022 10.7.3 Download: https://archives.boost.io/release/1.85.0/source/boost_1_85_0.7z unpack zip to boost_1_85_0 in console: cd boost_1_85_0 bootstrap.bat b2 -j%NUMBER_OF_PROCESSORS% toolset=msvc-14.3 address-model=64 --stagedir=.\lib64-msvc-14.3 --build-dir=.\__build --build-type=complete threading=multi architecture=x86 stage --with-date_time --with-graph --with-nowide --with-test --width-config --with-system --with-filesystem --with-serialization --with-locale --with-log result - lib64-msvc-14.3\lib\cmake gets created - but no libs that is my default build style up to 1.84 the output of bootstrap.bat https://pastebin.com/DQUVe3QR the output of b2 run https://pastebin.com/sJqGLDE7 it seems that all libs are ignored someway any idea?

2 2

[release] Master branch closes for the 1.86.0 beta release on WEDNESDAY
by Marshall Clow 08 Jul '24

08 Jul '24

Calendar is here: https://www.boost.org/development/ — The Release Managers

1 0

New Boost website ready for launch
by Joaquin M López Muñoz 06 Jul '24

06 Jul '24

Hi everyone, As most of you know, the new Boost website has been in the works for quite a long time: last week we've fixed the last showstopper issues and are now in a position to launch it publicly and announce to the wider community! See the launch-ready website at: https://boost.io The new website is ready to replace the current one at boost.org any time we want. The old site has served us well for 25 years, and it deserves to be given a retirement permit. OVERVIEW The new website is organized in five top-level sections: * News: an aggregator of internal announcements, blog articles, videos, etc. related to the Boost project. * Learn: comprehensive and completely rewritten tutorials and reference material for users, contributors and review participants. Check this out: there's a ton of new stuff here. * Community: links to the various discussion venues for Boost (mailing lists, Slack groups, X, etc.). * Libraries: revamped directory of Boost libraries, with integrated access to version-specific docs, repos, and more. * Releases: access to release notes, download binaries and source code for all Boost versions from 1.16.1 up to the current one. Users can navigate the website anonymously or log in to be able to contribute to the News section, receive notifications etc. The site uses responsive design to work on wide screens as well as your mobile device. Also, check the light and dark modes at the top-right corner :-) FEEDBACK AND FUTURE The evolution of the website does not stop here. We have quite a backlog of issues and new features registered at: https://github.com/boostorg/website-v2/issues https://github.com/boostorg/website-v2-docs/issues But we're also expecting your feedback! Please let us know what you think of the website and ways to improve it. I will personally make sure that all comments and suggestions are properly addressed. Ways to contribute: * Through the mailing list or the #boost-website group at cpplang.slack.com. * Filing issues directly at https://github.com/boostorg/website-v2 (website proper) and https://github.com/boostorg/website-v2 (learning material). * Learning material has an "Edit this page" link from where you can fork any documentation section and propose changes through a pull request. * Reach out to me anyway you'd like. ACKNOWLEDGEMENTS There are just too many individuals to list here who had contributed to the new website --my thanks to all of them. Let me mention some of the people I have worked with the most in the last two months, when I took over the PM role for this launch effort. * The people at REVSYS (Frank Wiles, Lacey Henschel) and Spencer Strickland built the Django-based backend and most of the frontend. Kenneth Reitz and Julio C. Estrada have been working tirelessly to close functionality gaps and fix remaining issues up to launch status. * Peter Turcan is the main author of the new learning material featured in the website. Again, check it out and help us spot glitches or propose new topics to work on. * Sam Darwin, who's already the Atlas upon whom the current Boost infrastructure rests, has double down on his responsibilites to set up and take care of this new backend. * René Rivera wrote many of the scripts that power the old website and has assisted us in the migration process with his expertise and unique insights into the particulars of Boost internal procedures. * Many people have filed issues during development, but the record holder is Andrey Semashev (39 tickets and counting). His suggestions and active involvement in the fixing process have made the website a better place. Best, Joaquín M López Muñoz

5 8

[release] The 1.86.0 release will close for major changes WEDNESDAY
by Marshall Clow 02 Jul '24

02 Jul '24

Calendar here: https://www.boost.org/development/ Next deadline: The master branch will close for the beta next Wednesday. — The release managers

3 2

1.86 release
by Andrey Semashev 01 Jul '24

01 Jul '24

Hi, Are we behind the 1.86 release schedule?

3 3

In Response to Mr. Falco's June 2024 Letter
by Kristen Shaker 01 Jul '24

01 Jul '24

Hello Boost Community, My name is Kristen. Admittedly, I am not the most active participant on the boost mailing list. However, I do serve on the Boost Foundation Board of Directors as Board Chair. It is lovely to e-meet you; Hopefully I'll have the opportunity to get to know you better during the course of my tenure. Recently, we became aware of a letter that was circulated to the Boost developer community. The Boost Foundation Board of Directors have penned the following note in response to that letter. _____________________________________ Dear Boost Community Members, Recently, Mr. Falco distributed a letter indicating intent to a) rescind his offer of hosting a new boost.org website, b) retract his agreement to retire the @BoostLibraries account on X in favor of the established @Boost_Libraries, c) create a new set of Boost mailing lists on boost.io, and d) attempt to purchase the boost.org domain name from Beman Dawes’s estate. While we are surprised and saddened by this turn of events, we agree with Mr. Falco that cutting ties between the C++ Alliance and the Boost Foundation is in everyone’s best interests. That being said, we want to acknowledge Mr. Falco and his employees’ tremendous contributions toward a modernized Boost website and significant investment in maintaining and extending the Boost Libraries. On March 28th, 2024, the Foundation voted to point the boost.org domain name at Mr. Falco’s new site. Given that we had every intention to move forward we were shocked to hear that Mr Falco felt we were “holding [his] work hostage.” The Boost Foundation was entirely unaware of Mr. Falco’s attempts to purchase the boost.org domain name. We were not consulted until it became clear to Mr. Falco that to proceed with the transaction, he would need the login credentials for the domain name provider. At that point, Mr. Falco did contact a board member requesting the credentials, which were not provided to him. We were hesitant to discuss these events publicly, but since Mr. Falco has openly described his attempts to purchase the boost.org domain name, this public response seems appropriate. The fact that he took these steps without coordinating with—or even notifying— the Boost Foundation, has shaken our confidence in the Alliance and Mr. Falco. While we very much appreciate Mr. Falco's financial investment, nonprofits like Boost are not—nor should they be—beholden to their largest financial contributors. We are committed to continuing to foster a collaborative environment where C++ developers can contribute great ideas to the open source community. Boost's consensus-based process is not always the fastest way to the best result, but it is consistent with that commitment. Ideally, Mr. Falco would be interested in contributing financially to a worthy cause without assuming control over the Libraries, but his letter indicates otherwise. Therefore, we agree with Mr. Falco’s assessment that there is no viable path forward for further coordination between The C++ Alliance and The Boost Foundation. We do, however, wish Mr. Falco and the Alliance all the best in their continued efforts to improve the C++ ecosystem. Sincerely, The Boost Foundation Board of Directors

13 16

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

Test
by Andrey Semashev 26 Jun '24

26 Jun '24

Hello, testing.

3 3

test77
by sam＠cppalliance.org 26 Jun '24

26 Jun '24

qq

1 1

test6
by Sam Darwin 26 Jun '24

26 Jun '24

test6

2 1

FYI: recent VS2022 17.10.x gives "Boost toolset is unknown (compiler MSVC 19.40.33808.0)" warning - due to Microsoft changing of the toolset version
by Dennis Luehring 21 Jun '24

21 Jun '24

...using Boost only CMake configure The MSVC toolset will increment its minor version number from|19.39|(VS 2022 v17.9) to|19.40|(VS 2022 v17.10). https://devblogs.microsoft.com/cppblog/msvc-toolset-minor-version-number-14… is still useable - did not check if building boost is a problem

2 3

[boost.QVM] can you explain quaternions in the docs?
by Andrzej Krzemienski 19 Jun '24

19 Jun '24

Hi Everyone, I landed on this library docs when trying to learn what quarterions are for. Although the library has a vast documentation it doesn't explain what quaternions are and why they are used. When I was taught algebra for the purpose of computer graphics, vectors and matrices were on the table, but no quaternions. The examples show that I need to create a quaternion only to turn it into a rotation matrix. I am pretty sure there has to be more to it. Could I request an introduction section in the docs that would explain what quaternions are and why one would want to use them? The corresponding GitHub issue: https://github.com/boostorg/qvm/issues/51 Regards, &rzej;

5 5

CppCast: Boost, The Beman Project and Beyond
by Niall Douglas 16 Jun '24

16 Jun '24

Given that some on here were expressing surprise at recent goings on, I thought in case nobody had seen it yet listening to this might be useful: https://cppcast.com/boost-the_beman_project_and_beyond/ Our own Zach Laine explains some of what's been going on behind the scenes. Niall

2 1

[Newbie] Problem receiving data with asio::serial_port
by Stefano Mora 14 Jun '24

14 Jun '24

Hi all, I’m writing a Qt application running on both Windows and MacOs platforms. The application is based on CMake project that includes boost-asio package 1.84.0 by vcpkg packager. The application must communicate with a board by USB cable = virtual serial port. I’m handling the communication with a small wrap around the asio::serial_port object, found in sample https://github.com/fedetft/serial-port/tree/master/2_with_timeout The problem is on MacOS platform; Windows version works correctly. The problem is that after some data exchanges (they are correct) the program does not receive a reply (with the TIMEOUT exception) and, after that, it receives only system_error = 89. This is a chunk of my log: ... ( I send a command and I receive the reply) [ReceiveLog] start [TP] start SendCommand 'log export' [WriteCommand] Byte[] Write - cmd: 'log export' [WaitForResponse] ms 1000 RX [34] : ' log export -> XModem receive file' [SendCommand] response: ' log export -> XModem receive file' [ReceiveLog] response1: 'XModem receive file' matching: 'XModem receive file' [ReceiveLog] ok -> XMODEM (now I send a byte to start the data from the board - 3 attempts) > Write BEGIN DATA RECEIVE .. [WaitForXModemResponse] ms 4000 [WaitForXModemResponse] TIMEOUT TO diff: 4 > Write BEGIN DATA RECEIVE .. [WaitForXModemResponse] ms 4000 [ToSerial][readCompleted] error system:89 [ToSerial][readCompleted] byteTransf 0 [WaitForXModemResponse] Boost System_error > Write BEGIN DATA RECEIVE .. [WaitForXModemResponse] ms 4000 [ToSerial][readCompleted] error system:89 [ToSerial][readCompleted] byteTransf 0 [WaitForXModemResponse] Boost System_error [TP][ReceiveLog] start XMODEM: 0 (now I sent an ACK, just to try ...) [WaitForXModemResponse] ms 1000 [ToSerial][readCompleted] error system:89 [ToSerial][readCompleted] byteTransf 0 [WaitForXModemResponse] Boost System_error [dlThread] ReceiveLog ret: 0 The read function is simply set the timeout and read 133 bytes: ... _serialPort.setTimeout( boost::posix_time::millisec(timeout)); char data[XMODEM_PACKET_LENGTH]; try { _serialPort.read( data, XMODEM_PACKET_LENGTH); ... } catch(timeout_exception){ ... } catch(boost::system::system_error){ ...} Please what error 89 means (in MACos context)? Any idea on how to exit from this situation? Thanks! Regards

2 8

CMake and Boost
by Robert Ramey 12 Jun '24

12 Jun '24

I'm trying to figure out how to switch to CMake to build and test my libraries. I have some experience with this as I've made such files on sort of an experimental/prototype basis. However it's been some time since I messed with this so a forgot a lot. Now I'm getting serious so I have some questions. I've looked over the official CMake documentation. It seems complete but some stuff is not well explained. I've spent some time studying https://github.com/boostorg/cmake at I'm beginning to see what I have to do. Never-the-less, I still have a few questions: 1) The first lines show mkdir __build cd __build cmake .. cmake --build . Does this presume that one starts from the library directory? Does this syntax work for out of source tree builds? That is, would the following work? mkdir /temp/__build cd /temp/__build cmake .. cmake --build . (very confusing usage of leading __) ahhhh - I see a problem. I'm thinking of starting from within the directory of a particular library. I'm presuming "modular boost". Is this supported? 2) BOOST_INCLUDE_LIBRARY I would like my CMakeLists.txt file to explicitly list the direct antecedent libraries (dependencies - bad word usage). So I'd expect to see something like add_directory(../filesystem) add_directory(../regex) ... So I could just cd to .../libs/serialization cmake --build and have it build the antecedent if and only if required. 3) CMAKE_INSTALL_INCLUDEDIR I would prefer not to "install" (copy) the include files but just use the ones from their original locations. 4) BUILD_TESTING I would prefer to have my library source to look like: ... libs/serialization CMakeLists.txt // includes add_directory for subdirectorys build, test, example, profile and ... // includes add_directory for antecedent libraries like add_directory(../libs/filesystem) include // directory with include files for users of serialization library build(or src) // source files for library build CMakeLists.txt // to build library test CMakeLists.txt example CMakeLists.txt profile CMakeLists.txt Maybe the add_directory would be conditioned on a CMAKE variable. So if I invoke CMake --build test_polymorphic_binary_archive It would recursively (re)build everything necessary and nothing not necessary If I didn't specify a list of targets, it would recursively (re)build everything that needs (re)building. This seems totally reasonable and natural to me - it work like make - but better. It would dovetail with efforts to "modularize" boost. Users would only have to download libraries they actually use - if that's what they want. I realized I've glossed over a couple of details, in particular recursive inclusion of header files and likely some other stuff. I've also experimented with CMake enough to have a feeling that what I want to do is not possible. And this is the short version of what I'd like to do. Any thoughts on this?

4 5

[container] Draft development plan for Boost.Container
by Ion Gaztañaga 11 Jun '24

11 Jun '24

Hi to all, Boost.Container was accepted in 2011 when container classes were spun off from Boost.Interprocess to form a new library. At that time it offered new features like emulated move semantics for "classic" STL-like containers and some new classes like flat_map and stable_vector. During these years more containers/main features were added: - The scoped allocator Model was added in Boost 1.50 (2012) - static_vector was added in Boost 1.54 (2013) - small_vector was added in Boost 1.58 (2015) - Polymorphic Memory Resources were added in Boost 1.60 (2015) - devector was added in Boost 1.75 (2020) Lately I've been collecting some ideas about how to improve the library and keep it interesting/useful both for other Boost libraries and Boost users. I've somewhat formalized a bit some of those ideas and I'd like to share them here in order to obtain feedback from the developers. Here's the document: https://docs.google.com/document/d/1VdMTheFUczC946dP3VKPseOoUq3sVKjU73oMvK8… Note that this document does not outline a schedule for all those ideas, it's an initial description of possible developments that should be evaluated/prioritized, as developing a substantial subset of the proposals would be a huge task. Thanks in advance for your attention and comments. Best, Ion

8 23

b2 headers failing on windows?
by John Maddock 10 Jun '24

10 Jun '24

In latest CI runs, see: https://github.com/boostorg/math/actions/runs/9427754774/job/25973291514?pr… Any ideas? Thanks! John.

6 8

Boost Downloads
by Sam Darwin 07 Jun '24

07 Jun '24

Summary: Boost downloads will be hosted at a new location, with the URL format https://archives.boost.io/release/1.85.0/source/boost_1_85_0.tar.gz Details: During the last couple of years the Boost downloads have been hosted on JFrog Artifactory, and before that on Bintray. JFrog has been very generous in providing the bandwidth and hosting services. Recently, bandwidth increased into the 150TB/month range. JFrog requested the download be moved behind a CDN, or migrated to another service entirely. At the C++ Alliance, we have set up load balanced AWS EC2 instances, and configured a Fastly CDN, on the domain archives.boost.io. Fastly offered a discounted bulk rate based on the large amount of traffic. The boost.org website now shows links to the new CDN. If you are using any automated scripts that point to jfrog.io, the existing JFrog links will continue to function until December 2024. - Sam Darwin

4 5

Docs in release tarballs
by Ruben Perez 07 Jun '24

07 Jun '24

Hi all, For someone that hasn't been that long involved in Boost, it feels strange to distribute the documentation in the same release tarball as the code, specially considering the usual complains about "Boost size". I'm sure there are reasons behind it, and I'd like to learn about them. This is a candid question, out of being a newbie here. Thanks, Ruben

4 7

Re: [boost] Boost Downloads
by Tim Haines 06 Jun '24

06 Jun '24

> Summary: > > Boost downloads will be hosted at a new location, with the URL format > https://archives.boost.io/release/1.85.0/source/boost_1_85_0.tar.gz > > Details: > > During the last couple of years the Boost downloads have been hosted on > JFrog Artifactory, and before that on Bintray. JFrog has been very generous > in providing the bandwidth and hosting services. > > Recently, bandwidth increased into the 150TB/month range. JFrog requested > the download be moved behind a CDN, or migrated to another service entirely. > > At the C++ Alliance, we have set up load balanced AWS EC2 instances, and > configured a Fastly CDN, on the domain archives.boost.io. Fastly offered a > discounted bulk rate based on the large amount of traffic. > > The boost.org website now shows links to the new CDN. > > If you are using any automated scripts that point to jfrog.io, the existing > JFrog links will continue to function until December 2024. > > > - Sam Darwin I maintain the Boost spack package[1]. The versions currently available there go back to 1.39.0. However, the versions available on archives.boost.io only go back to 1.63.0. Are the older versions going to be available there or will they remain on the sourceforge hosting? Thanks. - Tim [1] https://github.com/spack/spack/blob/develop/var/spack/repos/builtin/package… P.S. I am terribly sorry if this messes up the thread. I get my messages in digest form and could not for the life of me figure out how to reply to your email directly to the list.

2 1

[JSON] Detect duplicate keys
by abbott＠dima.unige.it 04 Jun '24

04 Jun '24

Hi, Feature request: I would like the JSON parse to inform me that duplicate keys were encountered. I believe they are currently silently handled (with a last-one-wins strategy). Thanks, John Abbott

4 3

Mailman3
by Sam Darwin 04 Jun '24

04 Jun '24

Hi, Since the current Boost webserver and mailing list are quite out-of-date, it makes sense to consider the upgrade path. Mailman3 is a complete rewrite of the mailing list software. It's designed with multiple components: hyperkitty archives, postorius, and mailman-core. Dev instances have been installed. If you have any curiosity about testing mailman3 using your local email client, or sending feedback about the mailman3 experience, you can subscribe at https://lists.preview.boost.org. Send/receive emails. If you notice problems using mailman3, open an Issue at the Github repository cppalliance/boost-mailman. Now is the best time to discover issues, rather than after deployment. Lists at https://lists.preview.boost.org won't be maintained permanently. Any emails or accounts there will eventually be deleted. It's only a staging type environment. Working with the web developers we are planning to modify the appearance of the front-end UI, adding css styles, links to the boost website, and so on. Keep an eye on the test lists for updates. In the future when "going live", the idea will be to schedule (extended) planned downtime, and have a new server fully replace "lists.boost.org". Which specific boost mailing lists should be kept? It would be easier to avoid migrating all lists, if some of them are not active. Best Regards, Sam Darwin C++ Alliance

1 0

Decimal Floating Point Library Beta
by Matt Borland 31 May '24

31 May '24

Hello, For the past year Chris Kormanyos and I have been working on a new library to implement IEEE 754 decimal floating point types. We are pleased to announce the library is now in beta, and can be found at: https://github.com/cppalliance/decimal, and the documentation is at: https://cppalliance.org/decimal/decimal.html First, what are Decimal Floating Point Numbers? They are floating point numbers where the significand is stored in base-10 (decimal) instead of base-2 (binary). This means that numbers can be represented exactly avoiding cases such as the famous 0.1 + 0.2 != 0.3: https://0.30000000000000004.com. The library provides types decimal32, decimal64, and decimal128 as specified in IEEE 754 and STL-like functionality. The library is header-only, has no dependencies, and only requires C++14. It provides most of the STL functionality that you are familiar with such as <cmath>, <cstdlib>, <charconv>, etc. We are proceeding as a beta right now rather than pursuing complete boost review as we are missing STL features such as C++17 special math, and believe we can continue to increase performance. We do intend to go through the review process at a later time. Please give the library a go, and let us know how we can make it better. We look forward to any and all feedback. If you use the Cpplang slack channel I am active (from the Central European Time zone) on both #boost and #boost-decimal. On a personal note as of today I have also moved from being employed half-time to full-time with the C++ Alliance. This affords me a greater opportunity to develop and maintain new and existing Boost libraries. Matt Borland —- C++ Alliance Staff Engineer

8 15

test7
by Sam Darwin 30 May '24

30 May '24

test7

1 0

NVCC and Unit Test Framework.
by Allen Sanderson 29 May '24

29 May '24

Hello, I am trying to sort out an odd crash on exit while using NVCC (via Kokkos-CUDA) and the Boost Unit Test Framework. Here my are data points: Kokkos-CUDA with the Boost test tool infrastructure - Crash Kokkos-HIP with the Boost test tool infrastructure - works Kokkos-Serial with the Boost test tool infrastructure - works Pure CUDA with the Boost test tool infrastructure - works Serial with the Boost test tool infrastructure - works Kokkos-CUDA alone (e.g. normal application) - works For the first case I have three scenarios (only used to high the Kokkos usage - the code does not crash in Kokkos::initialize), two of which crash: if(true) Kokkos::initialize(argc,argv); crash in CUDA - SEGFAULTif(false) Kokkos::initialize(argc,argv); crash in elsewhere - Subprocess aborted#if 0 Kokkos::initialize() #endif No crash For the first scenario the call stack is the following: #0 0x00001555521b5d9a in ?? () from ./cuda/12.2.0/lib64/libcudart.so.12 #1 0x00001555521b8c14 in ?? () from ./cuda/12.2.0/lib64/libcudart.so.12 #2 0x000015555219d882 in ?? () from ./cuda/12.2.0/lib64/libcudart.so.12 #3 0x00001555521a072b in ?? () from ./cuda/12.2.0/lib64/libcudart.so.12 #4 0x000015554b3b5797 in __cxa_finalize () from /lib64/libc.so.6 #5 0x0000155551301a87 in __do_global_dtors_aux () from build_kokkos_cuda/library/Operators/libOperators-g.so.5.5.0 #6 0x00007fffffffad10 in ?? () #7 0x000015555532dcee in _dl_fini () at dl-fini.c:141 For second, the call stack is quite deep after the call to __cxa_finalize () otherwise the first four (4-7) are the same. At this point the only culprit I can perhaps point at is nvcc I know at that previous versions of Boost and nvcc did not get along. And such, wondering if the usage is a corner case because I know of another project that is successfully using all three Boost, Kokkos, and CUDA. I am using Boost 1.85, Kokkos 4.3, and CUDA 12.2. Any insight or thoughts ? Our unit test work with Kokkos-HIP so able to validate results. Allen Sanderson SCI Institute University of Utah

1 0

[release] Boost 1.85.0
by Marshall Clow 28 May '24

28 May '24

Release 1.85.0 of the Boost C++ Libraries is now available. These open-source libraries work well with the C++ Standard Library, and are usable across a broad spectrum of applications. The Boost license encourages both commercial and non-commercial use. This release contains two new libraries: * Boost.Charconv: A high quality implementation of <charconv> in C++11, from Matt Borland. * Boost.Scope: A collection of scope guard utilities and a unique_resource wrapper, from Andrey Semashev. The release also contains numerous enhancements and bug fixes for existing libraries. For details, including download links, see <http://www.boost.org/users/news/version_1.85.0> You can also download directly from: <https://boostorg.jfrog.io/artifactory/main/release/1.85.0/> To install this release on your system, see <http://www.boost.org/doc/libs/release/more/getting_started/index.html> Thanks to everyone who participated in this release. -- The Boost Release Team Marshall Clow, Glen Fernandes

6 25

OSTIF Boost security audit report
by Andrey Semashev 24 May '24

24 May '24

Hi, Recently, a security audit of several Boost libraries has been conducted. The audited Boost version was 1.83.0. The report is now published here: https://ostif.org/boost-audit-complete/ https://ostif.org/wp-content/uploads/2024/05/OSTIF-Boost-Report-PT-v1.4.pdf In short, the following libraries were audited: - Boost.Beast (1 medium issue) - Boost.DLL (1 informational issue) - Boost.Date_Time - Boost.Filesystem - Boost.GIL - Boost.Graph (1 low and 1 informational issues) - Boost.JSON - Boost.Program_Options - Boost.Regex (3 low issues) - Boost.String_Algo - Boost.URL - Boost.UUID No critical or high severity issues were identified. Of the 7 identified issues, 4 are marked as closed, meaning the issues are fixed. The remaining 3 are open and listed in Boost.Beast (medium), Boost.DLL (informational) and Boost.Graph (informational). During audit, several fuzzing harnesses were developed and added to OSS-Fuzz: https://github.com/google/oss-fuzz/tree/master/projects/boost In the report, there were also a few general recommendations given to improve project security: - Monitor OSS-Fuzz Reports - Implement a Vulnerability Disclosure Process - Implement Supply-Chain Attack Countermeasures - Improve the Documentation with Security Mechanisms and Assumptions - Avoid the Abuse of Asserts Also, one general recommendation to Boost users: - Perform Strict Input Validation You can find more details in the report. I'd like to emphasize the "Implement Supply-Chain Attack Countermeasures" part, which basically comes down to signing git tags and release tarballs. I think, our release process is indeed not very reliable, let's say, which showed during the past few releases: - there was instance when different tarballs for the same RC were generated from different git revisions - git tags for the release were missing or pointing to a wrong git commit Also, release tarballs on GitHub don't have hashsums or signatures attached. https://github.com/boostorg/boost/issues/838 For tarballs on jfrog, thankfully, there are hashsums published in the release notes. Perhaps, we could also publish .sig files for all tarballs, and also publish the public key to verify the signature on the website. Also, under "Implement a Vulnerability Disclosure Process" it is suggested to use GitHub Security Advisories[1] as the mechanism for reporting security issues. I've never used this tool, but perhaps it is worth enabling for boostorg on GitHub. Emailing library maintainers privately might not be a very reliable mechanism for such reports, given that maintainers may become inactive. [1]: https://docs.github.com/en/code-security/security-advisories/working-with-r…

5 10

Boost/CMake
by Robert Ramey 23 May '24

23 May '24

Anyone have first hand experience building/testing a boost library/application with CMake? I've found the github project for boost/Cmake. Can anyone point me to more useful information? Robert Ramey

15 41

Re: [boost] modern logic classes
by g.peterhoff＠t-online.de 18 May '24

18 May '24

> At this point I'd like to know if it's possible to thread mathematically the N-bool problem and create a library for generic multidimensional bool that works with templates allowing to determine N at compile time. Because in the future we should have a 8-bool implementation, and so on... Theoretically, it would (probably) be possible to provide N-valued logics. But that is beyond my knowledge. bool3/bool4(Belnap) are still manageable. For N-valued logics N>4, mathematicians would have to be consulted (as I said: I am not one). If you are asking about such things, perhaps temporal logics could also be provided https://en.wikipedia.org/wiki/Temporal_logic. But that's where I completely drop out.

1 0

modern logic classes
by g.peterhoff＠t-online.de 18 May '24

18 May '24

Hello, I would like to provide modern logic classes, please see https://github.com/boostorg/logic/issues/30 What are your opinions/comments on this? thx Gero

8 15

2024 Q1 Transparency report
by Louis Tatta 16 May '24

16 May '24

Hello, Louis Tatta here, CEO of The C++ Alliance, Inc, a registered 501(c)(3) non-profit organization dedicated to the support of C++. This is our Q1 2024 transparency report regarding our charitable work for the Boost C++ Library Collection. First, some background on our operations. The C++ Alliance seeks out highly talented and experienced C++ experts and hires them, usually full-time, so they can focus completely on their open-source projects. Our Staff Engineers maintain existing Boost libraries, write new Boost libraries, and contribute to other Boost projects. We employ IT experts full-time to maintain and improve the infrastructure which supports Boost, including the legacy web server, the Drone continuous integration servers, the scripts used to deploy GitHub Actions for Boost repositories, and the scripts which publish the Boost release. In addition, we provide on-demand technical support services for Boost authors and maintainers who have infrastructure-related problems. The Boost Mailing List continues to be the premier place for high-quality discussion of the Boost libraries and tangential C++ Standards related topics. The C++ Alliance supports the use of the mailing lists going forward. We are upgrading it to the latest Mailman version and building an optional web-based front-end allowing interaction using only a browser. We continue to operate the Official C++ Language Slack Workspace ( https://cpp.al/slack) which hosts the most popular interactive discussions regarding the Boost libraries. The C++ Alliance sponsors a paid plan to provide full history, video and audio conferences, collaboration tools, and unlimited document storage for seventeen dedicated Boost library channels and one main Boost discussion channel. Our largest project for Q1 2024 is the continuation of work on the new Boost website. The new site is a C++ social media portal with rich support for user-generated content and a powerful back-end which has visibility into the contributions made on GitHub and the release process. This allows us to deliver an elevated user experience with the hopes of attracting fresh talent to Boost. Also, note that the graphics on the website are hand-drawn by our contract artist and reflect our level of commitment to ensure that Boost, to put it simply, looks good. In Q1 2024 there were a total of two Boost Formal Reviews. One of the reviewed libraries is authored by a C++ Alliance Staff Engineer. None of the reviews were managed by C++ Alliance team members. Out of a total of sixteen submitted reviews for the quarter, eight were from C++ Alliance team members. This quarter, we increased our efforts to build Boost’s social media presence. There were a total of six messages from the @Boost_Libraries X (formerly Twitter) account, all submitted by C++ Alliance team members. Three of them contained artwork from Bob Ostrom commissioned by us. Messages containing images get three times more engagement than text-only messages. We believe that the X platform has unique strategic value for informing newer generations about the Boost value proposition. A total of $406,000 was spent on Boost-related contributions, broken down thusly (and rounded to the nearest thousand): Staff Engineers Compensation $317,000 Website Software Development $64,000 Server Hosting $25,000 During Q1 2024 we employed a total of 12 individuals to contribute to Boost. Here is a high-level summary of accomplishments: Sam Darwin (Chief Technical Officer) * Boost website maintenance and administration * Boost per-pull-request documentation previews * Boost Release Process development, maintenance, and administration * Boost Mailman services maintenance and upgrade * Boost GitHub Actions self-hosted runner project development * Boost Drone service administration and maintenance * New Boost website deployment, administration, and development Dmitry Arkhipov (Staff Engineer) * Boost.JSON maintenance Alan de Freitas (Staff Engineer) https://cppalliance.org/alan/2024/05/07/AlanQ1Update.html * Boost.URL maintenance * Mr. Docs project management (https://mrdocs.com) * GitHub actions support scripts for Boost CI (https://alandefreitas.github.io/cpp-actions/cpp-actions/index.html) Christian Mazakas (Staff Engineer) * Boost.Unordered evolution project * Boost.Buffers development (new library) * Boost.Http.Proto, Boost.Http.Io development (new libraries) Krystian Stasiowski (Staff Engineer) * Boost.StaticString maintenance * Mr. Docs Lead engineer (https://mrdocs.com/) * Clang/LLVM contributions Peter Turcan (Senior Technical Writer) * Boost User Guide development (new documentation) * Boost Contributor Guide (new documentation) * Boost Formal Reviews (new documentation) Matt Borland (Staff Engineer) * Boost.Decimal (proposed library) * Multi (https://github.com/correaa/Boost-Multi) review manager * Boost.Math maintenance Ruben Perez * Boost.PFR integration and maintenance work * Boost.MySQL maintenance (new, accepted library) * Boost.Charconv * User Guide, Contributor Guide contribution (new documentation) Mohammad Nejati (Staff Engineer) * Boost.Http.Proto and Boost.Buffers (new libraries) * Boost-Gecko (full-text site search) * Boost.Beast maintenance Fernando Pelliccioni (Staff Engineer) * Mr. Docs development (https://mrdocs.com/) Spencer Strickland (Senior Web Developer) * New website front-end and scripting Joaquin M Lopez Munoz (Staff Engineer) * Boost.Unordered evolution project lead * Boost.Bimap * Boost promotion and new website

1 0

Fwd: shared_mutex lock() issue
by Max 15 May '24

15 May '24

Hi, It looks like threads-devel is abandoned I posted here. I have tried boost::shared_mutex and found an issue. It looks like it doesn't work as expected. The problem is following code: void lock() { #if defined BOOST_THREAD_PROVIDES_INTERRUPTIONS boost::this_thread::disable_interruption do_not_disturb; #endif boost::unique_lock<boost::mutex> lk(state_change); state.exclusive_waiting_blocked=true; exclusive_cond.wait(lk, boost::bind(&state_data::can_lock, boost::ref(state))); state.exclusive=true; } On lines: state.exclusive_waiting_blocked=true; exclusive_cond.wait(lk, boost::bind(&state_data::can_lock, boost::ref(state))); Here the state is changed and new lock_shared() waits because can_lock_shared returns false in this case. It works as I think it should be. The when "old" readers unlocks mutex the last one unlock_shared() executes void unlock_shared() { ... if (state.no_shared()) { if (state.upgrade) { ... } else { state.exclusive_waiting_blocked=false; //lk.unlock(); } release_waiters(); } where resets state.exclusive_waiting_blocked value. Then notify 2 condition variables(in release_waiters): 1 for readers and 1 for writers. If the writer doesn't win this race and one of the waited readers will be the first one, the writer runs state_data::can_lock and it of course returns false. Then the writer goes to sleep again. But exclusive_waiting_blocked is still false. So in the high pressure of readers, this writer never gets a chance to get control in this case anymore until all readers are gone. This bug was introduced in 1.67 version, before the changes the code was: while (state.shared_count || state.exclusive) { state.exclusive_waiting_blocked=true; exclusive_cond.wait(lk); } but it not the same as (because exclusive_waiting_blocked reassigned): state.exclusive_waiting_blocked=true; exclusive_cond.wait(lk, boost::bind(&state_data::can_lock, boost::ref(state))) Best Regards, Maxim

1 0

Re: [boost] Problem with building 1.85.0
by Ted Lyngmo 15 May '24

15 May '24

Andrey Semashev wrote: > > If you're building Boost from git, you should run `./b2 headers` before building Boost. > > The output you posted is missing the actual compilation errors for these files. Check the earlier compiler messages for these files. Or run `./b2 -j8 --with-filesystem` to build specifically Boost.Filesystem and see the output. Ok, I added `./b2 headers` before `./b2 -j8 install` which didn't change anything that I could see. `./b2 -j8 --with-filesystem` then gave me this: ...patience... ...found 3209 targets... ...updating 46 targets... boost-install.generate-cmake-config- bin.v2/libs/headers/build/stage/boost_headers-config.cmake boost-install.generate-cmake-config- bin.v2/libs/filesystem/build/stage/boost_filesystem-config.cmake boost-install.generate-cmake-config-version- bin.v2/libs/headers/build/stage/boost_headers-config-version.cmake common.copy /home/ted/git/boost/stage/lib/libboost_atomic.so.1.85.0 ln-UNIX /home/ted/git/boost/stage/lib/libboost_atomic.so boost-install.generate-cmake-config- bin.v2/libs/atomic/build/stage/boost_atomic-config.cmake boost-install.generate-cmake-config-version- bin.v2/libs/atomic/build/stage/boost_atomic-config-version.cmake common.copy /home/ted/git/boost/stage/lib/libboost_atomic.a common.copy /home/ted/git/boost/stage/lib/cmake/BoostDetectToolset-1.85.0.cmake common.copy /home/ted/git/boost/stage/lib/cmake/boost_filesystem-1.85.0/boost_filesystem-config.cmake common.copy /home/ted/git/boost/stage/lib/cmake/Boost-1.85.0/BoostConfig.cmake common.copy /home/ted/git/boost/stage/lib/cmake/Boost-1.85.0/BoostConfigVersion.cmake common.copy /home/ted/git/boost/stage/lib/cmake/boost_headers-1.85.0/boost_headers-config.cmake common.copy /home/ted/git/boost/stage/lib/cmake/boost_headers-1.85.0/boost_headers-config-version.cmake common.copy /home/ted/git/boost/stage/lib/cmake/boost_atomic-1.85.0/boost_atomic-config-version.cmake common.copy /home/ted/git/boost/stage/lib/cmake/boost_atomic-1.85.0/libboost_atomic-variant-shared.cmake boost-install.generate-cmake-config-version- bin.v2/libs/filesystem/build/stage/boost_filesystem-config-version.cmake common.copy /home/ted/git/boost/stage/lib/cmake/boost_atomic-1.85.0/boost_atomic-config.cmake common.copy /home/ted/git/boost/stage/lib/cmake/boost_atomic-1.85.0/libboost_atomic-variant-static.cmake common.copy /home/ted/git/boost/stage/lib/cmake/boost_filesystem-1.85.0/boost_filesystem-config-version.cmake gcc.compile.c++ bin.v2/libs/filesystem/build/gcc-14/release/threading-multi/visibility-hidden/unique_path.o libs/filesystem/src/unique_path.cpp:57:10: fatal error: boost/scope/unique_fd.hpp: No such file or directory 57 | #include <boost/scope/unique_fd.hpp> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~ compilation terminated. "g++" -fvisibility-inlines-hidden -fPIC -m64 -pthread -O3 -finline-functions -Wno-inline -Wall -fvisibility=hidden -DBOOST_ALL_NO_LIB=1 -DBOOST_ATOMIC_DYN_LINK=1 -DBOOST_COBALT_USE_STD_PMR=1 -DBOOST_FILESYSTEM_DYN_LINK=1 -DBOOST_FILESYSTEM_HAS_DIRENT_D_TYPE -DBOOST_FILESYSTEM_HAS_FALLOCATE -DBOOST_FILESYSTEM_HAS_FDOPENDIR_NOFOLLOW -DBOOST_FILESYSTEM_HAS_INIT_PRIORITY -DBOOST_FILESYSTEM_HAS_POSIX_AT_APIS -DBOOST_FILESYSTEM_HAS_STATX -DBOOST_FILESYSTEM_HAS_STAT_ST_BLKSIZE -DBOOST_FILESYSTEM_HAS_STAT_ST_MTIM -DBOOST_FILESYSTEM_NO_CXX20_ATOMIC_REF -DBOOST_FILESYSTEM_SOURCE -DNDEBUG -I"." -I"libs/filesystem/src" -c -o "bin.v2/libs/filesystem/build/gcc-14/release/threading-multi/visibility-hidden/unique_path.o" "libs/filesystem/src/unique_path.cpp" ...failed gcc.compile.c++ bin.v2/libs/filesystem/build/gcc-14/release/threading-multi/visibility-hidden/unique_path.o... gcc.compile.c++ bin.v2/libs/filesystem/build/gcc-14/release/link-static/threading-multi/visibility-hidden/unique_path.o libs/filesystem/src/unique_path.cpp:57:10: fatal error: boost/scope/unique_fd.hpp: No such file or directory 57 | #include <boost/scope/unique_fd.hpp> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~ compilation terminated. "g++" -fvisibility-inlines-hidden -m64 -pthread -O3 -finline-functions -Wno-inline -Wall -fvisibility=hidden -DBOOST_ALL_NO_LIB=1 -DBOOST_ATOMIC_STATIC_LINK=1 -DBOOST_COBALT_USE_STD_PMR=1 -DBOOST_FILESYSTEM_HAS_DIRENT_D_TYPE -DBOOST_FILESYSTEM_HAS_FALLOCATE -DBOOST_FILESYSTEM_HAS_FDOPENDIR_NOFOLLOW -DBOOST_FILESYSTEM_HAS_INIT_PRIORITY -DBOOST_FILESYSTEM_HAS_POSIX_AT_APIS -DBOOST_FILESYSTEM_HAS_STATX -DBOOST_FILESYSTEM_HAS_STAT_ST_BLKSIZE -DBOOST_FILESYSTEM_HAS_STAT_ST_MTIM -DBOOST_FILESYSTEM_NO_CXX20_ATOMIC_REF -DBOOST_FILESYSTEM_SOURCE -DBOOST_FILESYSTEM_STATIC_LINK=1 -DNDEBUG -I"." -I"libs/filesystem/src" -c -o "bin.v2/libs/filesystem/build/gcc-14/release/link-static/threading-multi/visibility-hidden/unique_path.o" "libs/filesystem/src/unique_path.cpp" ...failed gcc.compile.c++ bin.v2/libs/filesystem/build/gcc-14/release/link-static/threading-multi/visibility-hidden/unique_path.o... gcc.compile.c++ bin.v2/libs/filesystem/build/gcc-14/release/threading-multi/visibility-hidden/directory.o libs/filesystem/src/directory.cpp:42:10: fatal error: boost/scope/unique_fd.hpp: No such file or directory 42 | #include <boost/scope/unique_fd.hpp> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~ compilation terminated. "g++" -fvisibility-inlines-hidden -fPIC -m64 -pthread -O3 -finline-functions -Wno-inline -Wall -fvisibility=hidden -DBOOST_ALL_NO_LIB=1 -DBOOST_ATOMIC_DYN_LINK=1 -DBOOST_COBALT_USE_STD_PMR=1 -DBOOST_FILESYSTEM_DYN_LINK=1 -DBOOST_FILESYSTEM_HAS_DIRENT_D_TYPE -DBOOST_FILESYSTEM_HAS_FALLOCATE -DBOOST_FILESYSTEM_HAS_FDOPENDIR_NOFOLLOW -DBOOST_FILESYSTEM_HAS_INIT_PRIORITY -DBOOST_FILESYSTEM_HAS_POSIX_AT_APIS -DBOOST_FILESYSTEM_HAS_STATX -DBOOST_FILESYSTEM_HAS_STAT_ST_BLKSIZE -DBOOST_FILESYSTEM_HAS_STAT_ST_MTIM -DBOOST_FILESYSTEM_NO_CXX20_ATOMIC_REF -DBOOST_FILESYSTEM_SOURCE -DNDEBUG -I"." -I"libs/filesystem/src" -c -o "bin.v2/libs/filesystem/build/gcc-14/release/threading-multi/visibility-hidden/directory.o" "libs/filesystem/src/directory.cpp" ...failed gcc.compile.c++ bin.v2/libs/filesystem/build/gcc-14/release/threading-multi/visibility-hidden/directory.o... gcc.compile.c++ bin.v2/libs/filesystem/build/gcc-14/release/link-static/threading-multi/visibility-hidden/directory.o libs/filesystem/src/directory.cpp:42:10: fatal error: boost/scope/unique_fd.hpp: No such file or directory 42 | #include <boost/scope/unique_fd.hpp> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~ compilation terminated. "g++" -fvisibility-inlines-hidden -m64 -pthread -O3 -finline-functions -Wno-inline -Wall -fvisibility=hidden -DBOOST_ALL_NO_LIB=1 -DBOOST_ATOMIC_STATIC_LINK=1 -DBOOST_COBALT_USE_STD_PMR=1 -DBOOST_FILESYSTEM_HAS_DIRENT_D_TYPE -DBOOST_FILESYSTEM_HAS_FALLOCATE -DBOOST_FILESYSTEM_HAS_FDOPENDIR_NOFOLLOW -DBOOST_FILESYSTEM_HAS_INIT_PRIORITY -DBOOST_FILESYSTEM_HAS_POSIX_AT_APIS -DBOOST_FILESYSTEM_HAS_STATX -DBOOST_FILESYSTEM_HAS_STAT_ST_BLKSIZE -DBOOST_FILESYSTEM_HAS_STAT_ST_MTIM -DBOOST_FILESYSTEM_NO_CXX20_ATOMIC_REF -DBOOST_FILESYSTEM_SOURCE -DBOOST_FILESYSTEM_STATIC_LINK=1 -DNDEBUG -I"." -I"libs/filesystem/src" -c -o "bin.v2/libs/filesystem/build/gcc-14/release/link-static/threading-multi/visibility-hidden/directory.o" "libs/filesystem/src/directory.cpp" ...failed gcc.compile.c++ bin.v2/libs/filesystem/build/gcc-14/release/link-static/threading-multi/visibility-hidden/directory.o... gcc.compile.c++ bin.v2/libs/filesystem/build/gcc-14/release/threading-multi/visibility-hidden/operations.o libs/filesystem/src/operations.cpp:120:10: fatal error: boost/scope/unique_fd.hpp: No such file or directory 120 | #include <boost/scope/unique_fd.hpp> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~ compilation terminated. "g++" -fvisibility-inlines-hidden -fPIC -m64 -pthread -O3 -finline-functions -Wno-inline -Wall -fvisibility=hidden -DBOOST_ALL_NO_LIB=1 -DBOOST_ATOMIC_DYN_LINK=1 -DBOOST_COBALT_USE_STD_PMR=1 -DBOOST_FILESYSTEM_DYN_LINK=1 -DBOOST_FILESYSTEM_HAS_DIRENT_D_TYPE -DBOOST_FILESYSTEM_HAS_FALLOCATE -DBOOST_FILESYSTEM_HAS_FDOPENDIR_NOFOLLOW -DBOOST_FILESYSTEM_HAS_INIT_PRIORITY -DBOOST_FILESYSTEM_HAS_POSIX_AT_APIS -DBOOST_FILESYSTEM_HAS_STATX -DBOOST_FILESYSTEM_HAS_STAT_ST_BLKSIZE -DBOOST_FILESYSTEM_HAS_STAT_ST_MTIM -DBOOST_FILESYSTEM_NO_CXX20_ATOMIC_REF -DBOOST_FILESYSTEM_SOURCE -DNDEBUG -I"." -I"libs/filesystem/src" -c -o "bin.v2/libs/filesystem/build/gcc-14/release/threading-multi/visibility-hidden/operations.o" "libs/filesystem/src/operations.cpp" ...failed gcc.compile.c++ bin.v2/libs/filesystem/build/gcc-14/release/threading-multi/visibility-hidden/operations.o... ...skipped <pbin.v2/libs/filesystem/build/gcc-14/release/threading-multi/visibility-hidden>libboost_filesystem.so.1.85.0 for lack of <pbin.v2/libs/filesystem/build/gcc-14/release/threading-multi/visibility-hidden>directory.o... ...skipped <p/home/ted/git/boost/stage/lib>libboost_filesystem.so.1.85.0 for lack of <pbin.v2/libs/filesystem/build/gcc-14/release/threading-multi/visibility-hidden>libboost_filesystem.so.1.85.0... ...skipped <p/home/ted/git/boost/stage/lib>libboost_filesystem.so for lack of <p/home/ted/git/boost/stage/lib>libboost_filesystem.so.1.85.0... ...skipped <pbin.v2/libs/filesystem/build/gcc-14/release/threading-multi/visibility-hidden>libboost_filesystem-variant-shared.cmake for lack of <pbin.v2/libs/filesystem/build/gcc-14/release/threading-multi/visibility-hidden>libboost_filesystem.so.1.85.0... ...skipped <p/home/ted/git/boost/stage/lib/cmake/boost_filesystem-1.85.0>libboost_filesystem-variant-shared.cmake for lack of <pbin.v2/libs/filesystem/build/gcc-14/release/threading-multi/visibility-hidden>libboost_filesystem-variant-shared.cmake... gcc.compile.c++ bin.v2/libs/filesystem/build/gcc-14/release/link-static/threading-multi/visibility-hidden/operations.o libs/filesystem/src/operations.cpp:120:10: fatal error: boost/scope/unique_fd.hpp: No such file or directory 120 | #include <boost/scope/unique_fd.hpp> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~ compilation terminated. "g++" -fvisibility-inlines-hidden -m64 -pthread -O3 -finline-functions -Wno-inline -Wall -fvisibility=hidden -DBOOST_ALL_NO_LIB=1 -DBOOST_ATOMIC_STATIC_LINK=1 -DBOOST_COBALT_USE_STD_PMR=1 -DBOOST_FILESYSTEM_HAS_DIRENT_D_TYPE -DBOOST_FILESYSTEM_HAS_FALLOCATE -DBOOST_FILESYSTEM_HAS_FDOPENDIR_NOFOLLOW -DBOOST_FILESYSTEM_HAS_INIT_PRIORITY -DBOOST_FILESYSTEM_HAS_POSIX_AT_APIS -DBOOST_FILESYSTEM_HAS_STATX -DBOOST_FILESYSTEM_HAS_STAT_ST_BLKSIZE -DBOOST_FILESYSTEM_HAS_STAT_ST_MTIM -DBOOST_FILESYSTEM_NO_CXX20_ATOMIC_REF -DBOOST_FILESYSTEM_SOURCE -DBOOST_FILESYSTEM_STATIC_LINK=1 -DNDEBUG -I"." -I"libs/filesystem/src" -c -o "bin.v2/libs/filesystem/build/gcc-14/release/link-static/threading-multi/visibility-hidden/operations.o" "libs/filesystem/src/operations.cpp" ...failed gcc.compile.c++ bin.v2/libs/filesystem/build/gcc-14/release/link-static/threading-multi/visibility-hidden/operations.o... ...skipped <pbin.v2/libs/filesystem/build/gcc-14/release/link-static/threading-multi/visibility-hidden>libboost_filesystem.a(clean) for lack of <pbin.v2/libs/filesystem/build/gcc-14/release/link-static/threading-multi/visibility-hidden>directory.o... ...skipped <pbin.v2/libs/filesystem/build/gcc-14/release/link-static/threading-multi/visibility-hidden>libboost_filesystem.a for lack of <pbin.v2/libs/filesystem/build/gcc-14/release/link-static/threading-multi/visibility-hidden>directory.o... ...skipped <p/home/ted/git/boost/stage/lib>libboost_filesystem.a for lack of <pbin.v2/libs/filesystem/build/gcc-14/release/link-static/threading-multi/visibility-hidden>libboost_filesystem.a... ...skipped <pbin.v2/libs/filesystem/build/gcc-14/release/link-static/threading-multi/visibility-hidden>libboost_filesystem-variant-static.cmake for lack of <pbin.v2/libs/filesystem/build/gcc-14/release/link-static/threading-multi/visibility-hidden>libboost_filesystem.a... ...skipped <p/home/ted/git/boost/stage/lib/cmake/boost_filesystem-1.85.0>libboost_filesystem-variant-static.cmake for lack of <pbin.v2/libs/filesystem/build/gcc-14/release/link-static/threading-multi/visibility-hidden>libboost_filesystem-variant-static.cmake... ...updated 30 targets... ...skipped 10 targets... <p/home/ted/git/boost/stage/lib/cmake/boost_filesystem-1.85.0>libboost_filesystem-variant-shared.cmake <p/home/ted/git/boost/stage/lib/cmake/boost_filesystem-1.85.0>libboost_filesystem-variant-static.cmake <p/home/ted/git/boost/stage/lib>libboost_filesystem.a <p/home/ted/git/boost/stage/lib>libboost_filesystem.so <p/home/ted/git/boost/stage/lib>libboost_filesystem.so.1.85.0 <pbin.v2/libs/filesystem/build/gcc-14/release/link-static/threading-multi/visibility-hidden>libboost_filesystem-variant-static.cmake <pbin.v2/libs/filesystem/build/gcc-14/release/link-static/threading-multi/visibility-hidden>libboost_filesystem.a <pbin.v2/libs/filesystem/build/gcc-14/release/link-static/threading-multi/visibility-hidden>libboost_filesystem.a(clean) <pbin.v2/libs/filesystem/build/gcc-14/release/threading-multi/visibility-hidden>libboost_filesystem-variant-shared.cmake <pbin.v2/libs/filesystem/build/gcc-14/release/threading-multi/visibility-hidden>libboost_filesystem.so.1.85.0 ...failed updating 6 targets... gcc.compile.c++ bin.v2/libs/filesystem/build/gcc-14/release/link-static/threading-multi/visibility-hidden/directory.o gcc.compile.c++ bin.v2/libs/filesystem/build/gcc-14/release/link-static/threading-multi/visibility-hidden/operations.o gcc.compile.c++ bin.v2/libs/filesystem/build/gcc-14/release/link-static/threading-multi/visibility-hidden/unique_path.o gcc.compile.c++ bin.v2/libs/filesystem/build/gcc-14/release/threading-multi/visibility-hidden/directory.o gcc.compile.c++ bin.v2/libs/filesystem/build/gcc-14/release/threading-multi/visibility-hidden/operations.o gcc.compile.c++ bin.v2/libs/filesystem/build/gcc-14/release/threading-multi/visibility-hidden/unique_path.o

4 4

Problem with building 1.85.0
by Ted Lyngmo 13 May '24

13 May '24

Hi! First, I'm not sure if this is the right place for this. https://svn.boost.org/trac/boost seems to be down so I'm not sure where to turn. When I try building 1.85 on Fedora 40 with g++ (GCC) 14.1.1 20240507 (Red Hat 14.1.1-1) I run into a problem. I'm preparing the build like this: git co master && \ git pull -r && \ git co boost-1.85.0 && \ git submodule update --recursive && \ ./bootstrap.sh --with-libraries=all --with-icu \ -with-python-version=3.12.3 --prefix=/home/ted/local && \ echo 'using mpi ;' >> project-config.jam Then building like this: ./b2 -j8 install It however ends like this: ... ...updated 18621 targets... ...skipped 30 targets... <p/home/ted/local/lib/cmake/boost_fiber-1.85.0>libboost_fiber-variant-shared.cmake <p/home/ted/local/lib/cmake/boost_filesystem-1.85.0>libboost_filesystem-variant-shared.cmake <p/home/ted/local/lib/cmake/boost_filesystem-1.85.0>libboost_filesystem-variant-static.cmake <p/home/ted/local/lib/cmake/boost_log-1.85.0>libboost_log-variant-shared.cmake <p/home/ted/local/lib/cmake/boost_log_setup-1.85.0>libboost_log_setup-variant-shared.cmake <p/home/ted/local/lib/cmake/boost_wave-1.85.0>libboost_wave-variant-shared.cmake <p/home/ted/local/lib>libboost_fiber.so <p/home/ted/local/lib>libboost_fiber.so.1.85.0 <p/home/ted/local/lib>libboost_filesystem.a <p/home/ted/local/lib>libboost_filesystem.so <p/home/ted/local/lib>libboost_filesystem.so.1.85.0 <p/home/ted/local/lib>libboost_log.so <p/home/ted/local/lib>libboost_log.so.1.85.0 <p/home/ted/local/lib>libboost_log_setup.so <p/home/ted/local/lib>libboost_log_setup.so.1.85.0 <p/home/ted/local/lib>libboost_wave.so <p/home/ted/local/lib>libboost_wave.so.1.85.0 <pbin.v2/libs/fiber/build/gcc-14/release/threading-multi/visibility-hidden>libboost_fiber-variant-shared.cmake <pbin.v2/libs/fiber/build/gcc-14/release/threading-multi/visibility-hidden>libboost_fiber.so.1.85.0 <pbin.v2/libs/filesystem/build/gcc-14/release/link-static/threading-multi/visibility-hidden>libboost_filesystem-variant-static.cmake <pbin.v2/libs/filesystem/build/gcc-14/release/link-static/threading-multi/visibility-hidden>libboost_filesystem.a <pbin.v2/libs/filesystem/build/gcc-14/release/link-static/threading-multi/visibility-hidden>libboost_filesystem.a(clean) <pbin.v2/libs/filesystem/build/gcc-14/release/threading-multi/visibility-hidden>libboost_filesystem-variant-shared.cmake <pbin.v2/libs/filesystem/build/gcc-14/release/threading-multi/visibility-hidden>libboost_filesystem.so.1.85.0 <pbin.v2/libs/log/build/gcc-14/release/threading-multi/visibility-hidden>libboost_log-variant-shared.cmake <pbin.v2/libs/log/build/gcc-14/release/threading-multi/visibility-hidden>libboost_log.so.1.85.0 <pbin.v2/libs/log/build/gcc-14/release/threading-multi/visibility-hidden>libboost_log_setup-variant-shared.cmake <pbin.v2/libs/log/build/gcc-14/release/threading-multi/visibility-hidden>libboost_log_setup.so.1.85.0 <pbin.v2/libs/wave/build/gcc-14/release/threading-multi/visibility-hidden>libboost_wave-variant-shared.cmake <pbin.v2/libs/wave/build/gcc-14/release/threading-multi/visibility-hidden>libboost_wave.so.1.85.0 ...failed updating 6 targets... gcc.compile.c++ bin.v2/libs/filesystem/build/gcc-14/release/link-static/threading-multi/visibility-hidden/directory.o gcc.compile.c++ bin.v2/libs/filesystem/build/gcc-14/release/link-static/threading-multi/visibility-hidden/operations.o gcc.compile.c++ bin.v2/libs/filesystem/build/gcc-14/release/link-static/threading-multi/visibility-hidden/unique_path.o gcc.compile.c++ bin.v2/libs/filesystem/build/gcc-14/release/threading-multi/visibility-hidden/directory.o gcc.compile.c++ bin.v2/libs/filesystem/build/gcc-14/release/threading-multi/visibility-hidden/operations.o gcc.compile.c++ bin.v2/libs/filesystem/build/gcc-14/release/threading-multi/visibility-hidden/unique_path.o Building boost-1.84.0, or earlier, the same way doesn't show any signs of problems. Is my bootstrapping done in the wrong way? I've used the same way for a long time, but I might just have been lucky that it has worked :) Br, Ted

2 1

What is this "Beman Project Development"?
by René Ferdinand Rivera Morell 12 May '24

12 May '24

I got the email below from discourse.boost.org (I had subscribed long ago). So getting something was not unexpected. What I'm wondering about are this: Q: What is this new "Beman Project Development" thing about? A: It's something from C++Now initiated by The Boost Foundation (DBA) Q: Did they get permission from the Beman family to use Beman Dawes' name this way? A: ?? ---------- Forwarded message --------- From: Jeff Garland via Beman Project <notifications(a)boost.discoursemail.com> Date: Fri, May 3, 2024 at 10:19 AM Subject: [Beman Project] [Beman Project Development] Becoming a member of the beman-project github Jeff-Garland <https://discourse.boost.org/u/jeff-garland> May 3 Please send your github id to @Jeff-Garland <https://discourse.boost.org/u/jeff-garland> @dsankel <https://discourse.boost.org/u/dsankel> or @bretbrownjr <https://discourse.boost.org/u/bretbrownjr> via DM. ------------------------------ Visit Topic <https://discourse.boost.org/t/becoming-a-member-of-the-beman-project-github…> or reply to this email to respond. To unsubscribe from these emails, click here <https://discourse.boost.org/email/unsubscribe/63382355ff9c551129d38f2a59078…> . -- -- René Ferdinand Rivera Morell -- Don't Assume Anything -- No Supone Nada -- Robot Dreams - http://robot-dreams.net

13 43

What is this "Beman Project Development" exactly
by Robert Ramey 10 May '24

10 May '24

I confess that I'm totally mystified by this. I've looked over the web page and it doesn't help me. Here is the "mission statement" from the Boost Foundation website: "The Boost Foundation’s broad C++ mission is: (a) development of high quality, expert reviewed, legally unencumbered, open-source libraries, (b) inspiring standard enhancements, and (c) advancing and disseminating software development best practices. It does this by fostering community engagement, nurturing leaders, providing necessary financial/legal support, and making directional decisions in the event of Boost community deadlock." "Equally important to our mission is the guidance provided by our shared values. These are transparency, inclusivity, consensus-building, federated authorship, and community-driven leadership." Here is the "mission statement" from the Beman Project: "The Beman Project’s mission is to support the efficient design and adoption of the highest quality C++ Standard libraries through implementation experience, user feedback, and technical expertise. Founded at C++Now in 2024 the project strives to aggregate libraries proposed for ISO standardization making a simple usage experience for the C++ Community to try out new libraries. For library authors we assist by helping to make best modern development practices easy. Including CI, coverage, and packaging." Seems to me that they are essentially the same with different wording (excluding the woke paragraph it the Boost Foundation version. A couple miscellaneous questions: a) Why is the Boost Foundation website not part of the Boost.org website? b) So what's the point of all this? Who has promoted/championed it? What is their motivation. Extremely odd to me. add your own questions here. Personally I'd like to see the following: a) consolidation of all this under one umbrella b) More transparency in selection of board of directors. More direct influence on the part of library creators and users. I don't have any idea how to achieve this without creating caos though. c) Distancing Boost from the C++ standard. Boosts original mission was accomplished when the standards committee incorporated a large part of boost directly into the standard. Since then boost's policy of working with the standard library is very confusing. Are we an alternative? or are trying to create new (better?) standard library components. Or are we trying to create canonical implementations of the standard library components? The standard committee is flailing around itself. Three way branch? executors? Does something as elaborate as ranges belong in a standard library? What about testing the standard library? How do we do this? or Not. Do I incorporate the standard library in my heart pacemaker app? Without being able to test any of it? Oh let's not forget "modules" I've been reading up on it and it seems at most a half-baked idea. So boost should only focus on the standard to the extent that it needs to in order to make it's own libraries work. Sorry, I'm just not understanding any of this. Robert Ramey

7 11

Boost Foundation annual meeting in Aspen
by David Sankel 07 May '24

07 May '24

Hi all! We held our annual Boost Foundation meeting at C++Now last week. At this annual meeting we elect officers for an annual term and directors for staggering two-year terms. Glen Fernandes and Peter Dimov had terms expiring this year and were re-elected for another two-year term. We additionally added Matthew Guidry, who has been regularly active in foundation work, to the director roster. Congrats Matthew! Class A (Terms Expiring 2025) - Bob Steagall [BS] - David Sankel [DS] - Michael Caisse [MJC] - Zach Laine [ZL] - Inbal Levi [IL] - Jeff Garland [JG] - Kristen Shaker [KS] Class B (Terms Expiring 2026) - Glen Fernandes [GF] - Peter Dimov [PD] - Matthew Guidry [MG] - (4 vacant slots) We additionally made officer selections. I will continue for another year as Executive Director, but have stepped down as Chair of the Board of Directors. Kristen Shaker has volunteered to take this on (congrats Kristen!). Zach Laine has agreed to take on the Safety and Inclusion Chair role in her place. Here is the list of officers: - Board of Directors, Chair: Kristen Shaker - Board of Directors, Vice Chair: Glen Fernandes - Conference Chair: Bob Steagall - Director of Summer of Code: Inbal Levi - Executive Director: David Sankel - Secretary: Michael Caisse - Treasurer: Zach Laine - Standardization Chair: Jeff Garland - Safety and Inclusion Chair: Zach Laine We also decided to take down discourse.boost.org due to a general lack of interest by those active in the Boost project. The instance will be utilized by the Beman project <https://www.bemanproject.org/>, an independent initiative focused on providing implementations of libraries proposed for the C++ standard. That's all for now! -- David

1 0

Looking for review manager for async_mqtt
by Takatoshi Kondo 06 May '24

06 May '24

Hi, I've proposed a MQTT communication library based on Boost.Asio. https://github.com/redboltz/async_mqtt Fortunately, I got two endorsements, so far. Thank you Klemens and JoaquÃn. https://lists.boost.org/Archives/boost/2024/04/256650.php https://lists.boost.org/Archives/boost/2024/04/index.php However, I couldn't find a review manager, so far. https://www.boost.org/development/submissions.html I think that I am at step4 and step5 in the Boost Library Submission Process. I'm looking for review managers for async_mqtt now. I think that Boost.Beast, Boost.MySQL, and Boost.Redis are developed on Boost.Asio. I referred to those libraries for async_mqtt development. async_mqtt is using Boost.Beast for WebSocket communication. If those libraries developers would be interested in review managers, I would appreciate it. Of course, any other people are welcome. Best Regards, Takatoshi Kondo

1 0

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

Compression libraries such as zlib and zstd ought to be first class boost libraries
by Nigel Stewart 05 May '24

05 May '24

Hello all, I've been having a fairly hard time enabling zlib and zstd for boost 1.85.0 so we can make use of the compression support in iostreams module. We do have some specifics - static linking, non-standard file names and not system-installed. Windows and Linux. For various reasons it looks like we're going to copy certain files into our modules, rather than puzzle over making this work. It's not ideal, but workable. But along the way it's become clear that this functionality is not first-class boost citizen. Such as the broken links in the documentation, and various historical questions via google reporting similar issues. There are also other copies of zlib in the beast tree, because it's obviously needed for HTTP stuff too. zstd too? So I did think that I should at least mention that zlib, zstd, bzip2 and xv-utils all ought to be promoted to first-class boost libraries even though the majority of the maintenance is coming from upstream. They ought to be part of the "big tarball" and enabled and built by default regardless of what happens to be installed on the system. The cmake stuff ought to "just work" the way it does for other boost modules. I'm not quite volunteering myself, but it seems like a start to pose the question. The developer experience could be significantly improved for this particular corner of things. - Nigel Stewart

7 24

Proposal for yet another MQTT library for Boost
by Takatoshi Kondo 01 May '24

01 May '24

Dear Boost Developers, I'd like to propose a MQTT library to the Boost Libraries. Repository link: https://github.com/redboltz/async_mqtt Document link: https://redboltz.github.io/async_mqtt/doc/5.0.0/index.html Here is characteristics of async_mqtt: - C++17 or later is required. - async_mqtt supports Boost.Asio style completion tokens. - e.g. use_future, deferred, use_awaitable, callback functions, etc - Not only MQTT client but also MQTT server is supported. - User can use this library to develop MQTT broker. - Sample MQTT broker application is included. - Both MQTT v3.1.1 and v5.0 are supported. - In addition, undetermined protocol version is supported for server implementation. In this case, the protocol version is decided when you receive CONNECT packet. - Continuous packet sending - Users can send the next MQTT packets before the previous sending is not completed (completion handler is not invoked yet). - Auto acquiring/mapping topic alias is supported. - In addition, when resending a PUBLISH packet after reconnecting, the topic alias is removed and the original topic is restored. It is required by MQTT v5.0 spec. - Packet based send()/recv() APIs. - MQTT has various packets and some of their fields are optional. In order to keep simple APIs, async_mqtt uses packet based APIs. - See https://redboltz.github.io/async_mqtt/doc/5.0.0/tutorial/send_recv.html - Layered archtecture - async_mqtt can have predefined TCP, TLS, WS, WSS, and user defined underlying layer. Users can access the underlying layer using next_layer() member function of MQTT endpoint. So you can configure any layers by yourself. e.g. tcp_no_delay, set send/recv buffer size, etc - See https://redboltz.github.io/async_mqtt/doc/5.0.0/tutorial/create_endpoint.ht… - High performance - See https://redboltz.github.io/async_mqtt/doc/5.0.0/performance.html Background I have developed another mqtt library mqtt_cpp https://github.com/redboltz/mqtt_cpp since 2015. It is widely used but has some limitations. For example: - The functions are directly mapped to packets(publish, subscribe, etc), so optional features are not designed cleanly. - Due to set_publish_hander / on_publish style handler design, Completion Token cannot be supported. Based on this 9years experience, I designed the new MQTT library. This is async_mqtt. I would appreciate if you could endorse this library. Regards, Takatoshi Kondo

3 4

Re: [boost] modern logic classes
by g.peterhoff＠t-online.de 29 Apr '24

29 Apr '24

Here is an update. Since a few boost libraries use tribool, these would have to be converted to bool3. Unfortunately it is not that easy to establish a new boost library. Especially if it is incompatible with previous implementations. thx Gero

1 0

Can we get rid of auto-linking?
by René Ferdinand Rivera Morell 29 Apr '24

29 Apr '24

Today I got bit by auto-linking again. As I forgot to define BOOST_ALL_NO_LIB in a CI build. I can't remember a time when auto-linking has been beneficial. And I've lost the number of times I've had to answer user questions with "Auto-linking is getting in the way. Define BOOST_ALL_NO_LIB and link normally." more times than I can count. If there was ever a benefit to auto-linking it has not surpassed the drawbacks. So.. Can we get rid of auto-linking? -- -- René Ferdinand Rivera Morell -- Don't Assume Anything -- No Supone Nada -- Robot Dreams - http://robot-dreams.net

7 15

Emitting complete type information in boost-python docstrings
by Jakob van Santen 29 Apr '24

29 Apr '24

Hello, I’m not sure if this is the right forum for this question, but here goes: I work on a large scientific codebase that is heavily tied to boost, and that most users interact with via boost-python. Lately I have been working on generating PEP 484 type stubs for the ~1000 classes it exposes in order to enable static type checking and code completion in editors. This required some modifications to boost-python itself in order to get complete type information into the generated docstrings, where it can be consumed by external tooling to generate stubs: https://github.com/boostorg/python/pull/417 I have found this quite useful, and suspect it might be useful for others as well to have it in a Boost release. Can anyone give me a pointer as to how to make that happen, or let me know where or whom I should be asking instead? I asked on cplusplus-sig(a)python.org <mailto:cplusplus-sig@python.org>, which was the place many years ago, but that list seems to have died out. Many thanks in advance! Cheers, Jakob ------------------------------------------------------- Jakob van Santen DESY - Deutsches Elektronen-Synchrotron Platanenallee 6, D-15738, Zeuthen Office 2L/32 +49 (0)33762-7-7233 -------------------------------------------------------

2 1

BOOST_THREAD_HAS_EINTR_BUG...
by David Bien 26 Apr '24

26 Apr '24

Not really sure where to bring this issue up. I have a singleton globals object with a session manager, share manager, etc. that is destroyed atexit() on final reference release. There are a few mutexes in the implementation. This functions fine on Windows, MacOS, etc - the globals object is released during atexit() and shutdown proceeds normally. Under Linux when BOOST_THREAD_HAS_EINTR_BUG is defined we SIGABRT at this: ~mutex() { BOOST_VERIFY(!posix::pthread_mutex_destroy(&m)); } The verify fails and we abort(). When I define BOOST_THREAD_HAS_NO_EINTR_BUG we do not abort - which means that posix::pthread_mutex_destroy() returns 0 in the case where BOOST_THREAD_HAS_NO_EINTR_BUG is defined and returns non-zero in the case of it not being defined. Guidance? Also point me at a better place for this discussion if there is such a place. Thanks, David Bien

3 10

question about singleton_pool
by 李重斌 26 Apr '24

26 Apr '24

I want to use singleton_pool to manage memory. This is just an example which tests it. My question: the first time i allocate 100 spot object, and free them. If i allocate some spot objects, and the number of them is less than 100. no more memory is needed, there is no need to allocate memory from os again. but the fact is another memory block is allocated. The first block is 4016 bytes (sizeof(Spot) = 40), the second block is 8016 bytes. This is not as my imagine. Is there something wrong with these code? ///////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////// std::cout << "size of Spot " << sizeof(Spot) << " bytes\n"; std::cout << "test singleton_pool firt time\n"; const size_t NumSpots = 100; Spot* p1 = static_cast<Spot*>(spot_pool::ordered_malloc(NumSpots)); for (size_t i = 0; i < NumSpots; i++) { p1[i].x = 1; p1[i].y = 1; } spot_pool::ordered_free(p1); std::cout << "test singleton_pool second time\n"; Spot* p2 = static_cast<Spot*>(spot_pool::ordered_malloc(NumSpots/2)); for (size_t i = 0; i < NumSpots/2; i++) { p2[i].x = 2; p2[i].y = 2; } spot_pool::ordered_free(p2); /////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

1 0

UUID design discussion
by Peter Dimov 26 Apr '24

26 Apr '24

We've been discussing some UUID design issues in, well, issues in the Uuid repo, namely https://github.com/boostorg/uuid/issues/96 and, for context, https://github.com/boostorg/uuid/issues/113. This topic might be of wide interest to developers, so I thought it would be better to have this list know about it. Anyone who has an opinion on the matter is welcome to express it in the issue, or here. In addition to the questions raised in #96, namely, how should the constructors and the accessors of `uuid` look like (once we somehow move away from the public `data` member), here are some more topics of interest: * Should a default-constructed `uuid` remain uninitialized, or should the default constructor produce the nil Uuid? (Uninitialized is not a good look in 2024 because safety. On the other hand, `new uuid[ 1048576 ]` will start doing a `memset`.) * At the moment wide strings are processed by the name generators by converting every wchar_t to 32 bit, then hashing the bytes, zeroes and all. This doesn't strike me as correct. I think that the string should be converted to UTF-8 on the fly (with 32 bit wchar_t assumed UTF-16 and 32 bit wchar_t assumed UTF-32.)

5 11

Re: [boost] modern logic classes
by g.peterhoff＠t-online.de 25 Apr '24

25 Apr '24

>> Hello, >> I would like to provide modern logic classes, please see https://github.com/boostorg/logic/issues/30 >> What are your opinions/comments on this? > Interesting idea. > But rather than messing with tribool, I'd prefer to just see a new library quadbool. I would also like tribool to be removed. But until then it still needs to be supported. regards Gero

1 0

[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

On Boost and modules
by Ruben Perez 12 Apr '24

12 Apr '24

Hi all, Following a recent conversation on the possibility to somehow enable Boost to be consumed using C++20 modules, I've jumped in and done a small research: https://anarthal.github.io/cppblog/modules René posted the link to r/cpp and it seems to have attracted some interest (https://www.reddit.com/r/cpp/comments/1bxggim/c20_modules_and_boost_an_anal…) It looks like a small fraction of users would consider consuming Boost as modules if there was the possibility (note that considering here is pretty far from actually doing it). Nevertheless, I'd like to know everyone's opinion on the subject. If we find a way to overcome the technical challenges that I manifest in the article, do you think a set of non-intrusive "module bindings" allowing users to consume Boost as a module could add any value to Boost? Thanks, Ruben.

14 62

Re: [boost] [release] Boost 1.85.0 Release Candidate 2 is available
by Glen Fernandes 11 Apr '24

11 Apr '24

I wrote: > I think we saw this before, but I couldn't figure it out: > https://github.com/boostorg/boost/issues/884 Many thanks to Sam Darwin for finding the cause (and looking into a long term solution in the new website release mechanism). Glen

1 0

[release] Boost 1.85.0 Release Candidate 2 is available
by Marshall Clow 11 Apr '24

11 Apr '24

The second 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: 06bdbef025de63a22baf997d49d34f38455975529ee05ab73379338e572d0df4 boost_1_85_0_rc2.zip 623a9e5288bae94c0c01b733873ea12613af35f4fc433059a0ddaa5cf0033ce1 boost_1_85_0_rc2.tar.bz2 f7b6b252f488dc8a386bfc79bf7197772c4400f847f0dee50754bb23847d40d2 boost_1_85_0_rc2.7z ec9347228d2c8a7189685b48fe4609a837d3dde45973d4457a8f2396d2c446da boost_1_85_0_rc2.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. 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

7 10

Is there an interest for an async JSON-RPC library in boost ?
by Quentin Chateau 11 Apr '24

11 Apr '24

A couple of years ago, I wrote packio, a library implementing asynchronous client and server for msgpack-rpc. Over time it evolved into something more generic, an async implementation of the JSON-RPC (https://www.jsonrpc.org/) spec with customizable serialization. It is built on top of asio, and boost.json is supported serializer. This means that with minimal efforts it could evolve into an implementation of JSON-RPC with no dependencies outside of boost - yet extendable. My question then is: is there an interest for it ? I'd probably need to invest a non trivial amount of time into making it boost-compliant and following up on the review process, so I'm wondering whether it is worth it or not. Note that there are two known limitations in my library: - No support for batch mode - No support for sharing a transport between a client and a server (not part of the spec, but requested by some users) I'm looking forward to get the community's opinion. You can check my library on GitHub (https://github.com/qchateau/packio) Feedback on either community's interest for such library, or plain comments on the library are welcome ! Quentin

6 5

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

[release] Boost 1.85.0 Release Candidate 1 is available
by Marshall Clow 08 Apr '24

08 Apr '24

The first 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: de84c538aaadf2388362e006d73d0be783541288d87a9ef68e906995efc2148d boost_1_85_0_rc1.tar.gz dd8baccd0b5ca534ad3717a07b426391fe6d49b6b84bf07d10e72792a5d1ba10 boost_1_85_0_rc1.7z 289ab7784b9297e13938876f698ced91f734f9a80f91099d35803b78d15c0210 boost_1_85_0_rc1.tar.bz2 84c35ef72efde30725de7bca8ccf399cd8d205a0d5b249465cf86c818291b7b7 boost_1_85_0_rc1.zip 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 22

[release] status of the Boost release
by Marshall Clow 08 Apr '24

08 Apr '24

The RC1 has been tested, and three problems have been reported (so far) * 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. And … Some additional libraries no longer build under C++03. (More than 1.84.0) The first one is the one that will impact the most people. Given that we want to fix that, we should fix the other two. I have asked the maintainers to merge the fixes to master. I will be out “watching the sky” tomorrow, but I will turn an RC2 either tomorrow night or Tuesday AM. This means that the release will almost certainly be delayed a couple of days past Wednesday. — Marshall

1 0

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

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

New website is open-source!
by Vinnie Falco 29 Feb '24

29 Feb '24

The new website and documentation are provided under the BSL, and the source repositories have been transferred to the Boost GitHub organization: https://github.com/boostorg/website-v2 https://github.com/boostorg/website-v2-docs While we sort out the unresolved issues related to the licensing of artwork and logo, the new website has moved to this temporary location for now: https://boost.io Please continue to experience, enjoy, and most importantly test the new website. A gentle reminder: it is not “finished” and likely will not be “perfect” for a while. The launch of the new website is the beginning of the journey rather than the end. Issues opened here will be acted upon by our dedicated website development team: https://github.com/boostorg/website-v2/issues For documentation-related issues, please open and monitor issues here: https://github.com/boostorg/website-v2-docs/issues Pull requests are always welcomed! Thanks

6 6

Boost.Parser questions
by Ruben Perez 29 Feb '24

29 Feb '24

Hi all, Sorry for jumping into this so late. I'll send my review tomorrow (that's still on time, isn't it?). I've been playing with the library and some questions popped up (please note I've no prior experience with Spirit): * What's the rationale for using operator[] for semantic actions (instead of a regular method like .action())? It looks like the parsing problem with inline lambdas could be easily worked around with this. * What's the rationale for using operator[] for directives? repeat(24)[p] looks like an over-complication, where a regular function repeat(24, p) would have just worked fine. * For non-recursive rules, what's the rationale on preferring the macro over something like: constexpr bp::rule<struct replacement_field_tag, std::string> replacement_field { "replacement_field", +bp::char_ }; * My use case involves parsing identifiers that can only contain ASCII lowercase, uppercase, digits and the underscore. I'd usually do this by defining a `bool is_identifier_char(char c)` function. This is what I could do with Boost.Parser - is there a better way (one that doesn't force me to list all valid characters)? constexpr const char name_chars[] = "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ_0123456789"; constexpr auto name_continuation_rng = std::span<const char>( name_continuation, sizeof(name_continuation) - 1 ); * What's the rationale behind the special naming convention for functions like _attr, _value, _globals and the like? Is there a reason why these can't be member functions of the context? * I've found really frustrating the generic lambda approach for semantic actions, since this completely inhibits tooling like clangd. Is there a reason why we can't have a public definition of the parsing context I could use in my functions? * I started my evaluation using clang-18 (Linux) but builds fail (seems to happen under all clang versions I tried). gcc-12 seems to work fine. Note that I'm using the develop branch, since I understand it contains the bug fixes for the issues that previous reviewers found. Regards, Ruben.

6 9

Boost.Parser review
by Richard 29 Feb '24

29 Feb '24

- Do you think the library should be accepted as a Boost library? Yes, this would be a great addition to Boost as a successor to Spirit. ====================================================================== Details: Note: I've only had time to read through the documentation. I'm familar with Spirit Classic, Spirit V2 and X3 parsing libraries and have done presentations on them using my own written example code. - What is your evaluation of the design? It's very similar to Boost.Spirit in philosophy, but other than the (optional) connection to Boost.Hana feels very decoupled from all the other bits of boost at a user level. Spirit's direct connection to things like Phoenix and Fusion made Spirit more complicated to explain to other developers and more difficult to use IMO. I understand why such things were done at the time of Boost.Spirit's writing, but being a C++17 library frees Boost.Parser from all these digressions which is good. The only thing obviously lacking were the binary parsers from Spirit V2 (bug filed). - What is your evaluation of the implementation? I've only reviewed the documentation, so I haven't had any time to dig into the implementation before the review deadline. I will say that there are no comments in the header files and that could be improved. It means that without consulting the tutorial documentation, I have no information in the included headers to guide me. - What is your evaluation of the documentation? The documentation is well written and follows a logical progression. It could use a math expression example as this is one of the most common reasons for needing to write a parser (typical C style math operators and precedence rules). The JSON example is nice (shows recursive rule parsing), but doesn't deal with operator precedence at all, so another detailed example showing this would be helpful. There were some minor typos and mistakes; I filed github issues on those. The concepts and reference section are just raw code dumps. They could use some additional doxygen style comments to tie things together. - What is your evaluation of the potential usefulness of the library? I would find this library a great successor to Spirit. - Did you try to use the library? With what compiler? Did you have any problems? No, I only had time to read through documentation. - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? I carefully read through every page of the documentation in the Tutorial section and skimmed over the reference section. - Are you knowledgeable about the problem domain? Yes. -- "The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline> The Terminals Wiki <http://terminals-wiki.org> The Computer Graphics Museum <http://ComputerGraphicsMuseum.org> Legalize Adulthood! (my blog) <http://LegalizeAdulthood.wordpress.com>

3 2

Boost.Parser review
by Ruben Perez 29 Feb '24

29 Feb '24

Hi all, This is my review of the proposed Boost.Parser. As in other occasions, I've taken a practical approach and used the library to (re)implement an existing, real feature in Boost.MySQL: client-side SQL formatting. This requires parsing a format string with replacement fields (similar to std::format strings). - What is your evaluation of the potential usefulness of the library? I think it's useful. Parsing is a common task, and this library simplifies it. I tend to prefer hand-crafted parsers in general, but libraries like the proposed tend to save time (and bugs). Also, many other users have manifested interest in it. I think the library is too heavyweight regarding compile times to be used in header-only libraries like Boost.MySQL, but it should be fine in compiled libraries and applications. - What is your evaluation of the design? I think it's pretty good in general. It allows you to express complex parsers using little code, which is good. In my opinion, it may be too generic (allowing any forward character range as input, for instance), which tends to increase complexity. I tend to prefer simpler approaches like the one Boost.URL uses - but I understand not everyone thinks like me, and there's a use case for each approach. As we discussed in previous posts, if I was writing this, I would have made some decisions differently (see https://lists.boost.org/Archives/boost/2024/02/256010.php) but I don't think there is any problem with the current design. The author has justified his decisions, and everything makes sense. - What is your evaluation of the implementation? I can tell it's really complex. I've attempted to debug a problem I had for which parser::trace::on wasn't enough (see below), and navigating the code was extremely difficult (reminds me of debugging Asio). This is probably inherent to the level of complexity of the library. This is not a criticism, but a thought I wanted to share. - Did you try to use the library? With what compiler? Did you have any problems? Yes, I did. As mentioned above, I re-implemented Boost.MySQL SQL formatting (see https://www.boost.org/doc/libs/master/libs/mysql/doc/html/mysql/sql_formatt…) using the proposed library. I've uploaded the code to a branch - you can check it here: https://github.com/boostorg/mysql/blob/66c99e31c9e548b6cf5b98e3d08255f22390… For reference, I've also pasted the grammar and the code at the end of this email. I've found the following problems: * Rule parsers using sequence + optional parsers yield unexpected results when the optional rule doesn't match. Making it a regular parser, rather than a rule parser, fixes the problem. The impact is that automatic replacement fields (i.e. `{}`) were being parsed as `{0}`. https://github.com/tzlaine/parser/issues/125 tracks this. * My clang-11 build fails. Looks like a concept is being used without proper protection, and the compiler doesn't support it. https://github.com/tzlaine/parser/issues/129 * My clang-16 build (and my local build attempts with clang 17, 18 and 19) fail because of a non-matching template redeclaration in parser/detail/text/transcode_view.hpp. I don't know if it's clang being picky or a clang bug. https://github.com/tzlaine/parser/issues/130 * My clang-14 build fails. This looks like it's hitting a clang + libstdc++ bug. See https://github.com/tzlaine/parser/issues/131. * My Apple clang 14 build fails. It also looks like an issue in clang or libc++. See https://github.com/tzlaine/parser/issues/133. * My MSVC 14.2 and 14.3 builds under C++17 fail (C++20 works fine). I've completely failed to parse what's the problem here. Description here: https://github.com/tzlaine/parser/issues/132 Some other minor problems: * As reported by other reviewers, enabling warnings=all or warnings=extra issues a lot of warnings. * [[no_unique_address]] (C++20) is used unprotected, which causes warnings under clang-7 (see https://github.com/tzlaine/parser/issues/128) * The CMakeLists.txt is not Boost-compliant (yet). * There is a #include <boost/hana.hpp>, which is not very friendly for compile-times - better replace it by the individual header that is needed. I've submitted the build logs together with all details I've been able to gather. I haven't been able to provide a minimal reproducible example for some of these (they were a lot and I had limited time). Note that all the builds referenced in the issues (except the OSX one) are run in Docker containers. If you have access to Docker, reproducing these environments should be trivial. Since I've done this in the past, should the author need any help with this, please let me know, I'm happy to help. Reading the CI files for the proposed library, I think compiler coverage is insufficient - for instance, there are no Linux clang builds, and the only Apple clang build uses clang 13 and C++17. - What is your evaluation of the documentation? The presentation is really good. I struggled to understand the concepts at first because I had no previous experience with parsers. I ended up reading the Bison concepts section (https://www.gnu.org/software/bison/manual/bison.html#Concepts) after which everything made perfect sense. I'd advise to expand the introduction a bit, or just point to other material for people like me. I fail to understand what RESOLVE means in https://tzlaine.github.io/parser/doc/html/boost_parser__proposed_/tutorial/…. Docs state "RESOLVE() is a notional macro that expands to the resolution of parse argument or evaluation of a parse predicate", but I'd say this resolution hasn't been explained yet - a link here would help. I've found the reference to be more confusing that helpful - it looks like a straight header dump. This is made worse by the concepts not being linked. Although it has many terrible things, the quickbook toolchain is (partly) capable of linking concepts - have a look at https://www.boost.org/doc/libs/master/libs/mysql/doc/html/mysql/ref/boost__…. This still has limitations, but I'd say it's better than what's currently there. If this is something you'd be interested in, please let me know and I will help you with it. - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? I've spent around 2 full days of work reading about the problem domain, studying the docs, writing my use case, diagnosing the problems I reported and writing this review. - Are you knowledgeable about the problem domain? I've never used a parsing library like this before. I've read about the problem in the past, but wasn't very knowledgeable about it before the review. I've written small parsers like the one for format strings in the past, though. - My conclusion My recommendation is to REJECT the library in its current form. This is not a hard rejection - I completely think this library can be useful to people. But I found too many problems while using it - too many to get it into Boost in its current form. I'd be happy to see this library being proposed again in a couple of months, once all the issues found during the review get fixed. - Affiliation disclosure Please note that I'm affiliated with the C++ Alliance. I'd like to thank Zach for proposing the library, and Marshall for managing the review. Regards, Ruben. - Reference: parsing code in Boost.MySQL /** * format-str = *( text | literal-opening-brace | literal-closing-brace | replacement-field ) * text = *( any characters except {} ) * replacement-field = "{" [ replacement-id ] "}" * replacement-id = ushort | field-name * field-name = (character a-z, A-Z, _) *( any characters 0-9, a-z, A-Z, _ ) */ // Note: globals is a format_state structure, which has member functions // to append raw text and replacement fields to the output string // Actions constexpr auto action_text = [](auto& ctx) { _globals(ctx).append_text(_attr(ctx)); }; constexpr auto action_replacement_field = [](auto& ctx) { const std::optional<std::variant<unsigned short, std::string>>& val = _attr(ctx); format_state& st = _globals(ctx); if (val) { if (const auto* idx = std::get_if<unsigned short>(&*val)) { st.append_indexed_field(*idx); } else { st.append_named_field(std::get<std::string>(*val)); } } else { st.append_auto_field(); } }; constexpr auto action_opening_brace = [](auto& ctx) { _globals(ctx).append_text("{"); }; constexpr auto action_closing_brace = [](auto& ctx) { _globals(ctx).append_text("}"); }; // Character ranges constexpr std::array<const char, 63> name_chars{ 'a', 'b', 'c', 'd', 'e', 'f', 'g', 'h', 'i', 'j', 'k', 'l', 'm', 'n', 'o', 'p', 'q', 'r', 's', 't', 'u', 'v', 'w', 'x', 'y', 'z', 'A', 'B', 'C', 'D', 'E', 'F', 'G', 'H', 'I', 'J', 'K', 'L', 'M', 'N', 'O', 'P', 'Q', 'R', 'S', 'T', 'U', 'V', 'W', 'X', 'Y', 'Z', '_', '0', '1', '2', '3', '4', '5', '6', '7', '8', '9' }; constexpr boost::span<const char, 53> name_start_chars{name_chars.data(), 53}; // Parsers and rules constexpr auto field_name = parser::char_(name_start_chars) >> *(parser::char_(name_chars)); constexpr auto replacement_id = parser::ushort_ | field_name; constexpr auto replacement_field = ('{' >> -replacement_id) > '}'; constexpr auto literal_open_brace = parser::lit("{{"); constexpr auto literal_close_brace = parser::lit("}}"); constexpr auto text = +(parser::char_ - '{' - '}'); constexpr auto format_str_parser = *( text[action_text] | literal_open_brace[action_opening_brace] | literal_close_brace[action_closing_brace] | replacement_field[action_replacement_field] ); // Top-level parsing function inline void parse_format_str(string_view format_str, format_context_base& ctx, span<const format_arg> args) { // By default, parser prints to cerr, which we don't want parser::callback_error_handler handler([](const std::string&) {}); // Create a parsing state format_state st(ctx, args); // Invoke the actual parsing bool result = parser::parse( format_str, parser::with_globals(parser::with_error_handler(format_str_parser, handler), st) ); // If there was an error, report it if (!result) { ctx.add_error(client_errc::format_string_invalid_syntax); } }

2 1

[release] The 1.85.0 release will close for major changes TOMORROW
by Marshall Clow 28 Feb '24

28 Feb '24

Calendar here: https://www.boost.org/development/ Next deadline: The master branch will close for the beta next Wednesday. — The release managers

1 0

Boost.Parser review by Tobias
by tobi＠die-loews.de 27 Feb '24

27 Feb '24

Boost.Parser review Why do we need a DSEL-Parser library in Boost: I think nobody, who once has written a parser with a DSEL (like e.g. Spirit) in C++, ever want's to go back to out off source parser-generators like yacc/bison or ANTLR (or even hand written parsers): it is so convenient having the parser definition as a grammar within the code. Additionally, you can quite easily hook into the parser (e.g. Spirit's Phoenix functions). So, IMHO there is definitely need for such C++ libraries. On the other hand, the task of creating such a library is very challenging and requires high expertise and coding standards, as library-users have to rely on its correctness. So, Boost with its standards and peer-review process is definitely the place for such a library. (Personally, I wouldn't use a parser-library the hasn't gone through such a process.) Should accept Boost.Parser into Boost? There are already three parser libraries in Boost: Spirt and its successors Qi and X3 - Spirit: very outdated interface, IIRC C++98 compatible, superseded by Qi - Qi: Simply a revolution in parsing! It was blowing my mind, when I first used it. The way attributes were composed and semantic actions could applied with Phoenix was totally exciting. But of course, there was also the downside of (very) long compilation-times and frustrating long error-messages when something got wrong. And (again IIRC) Qi came to life before C++11, so it is also C++98. - X3: I only wrote one larger X3 parser, and to be frank, IMHO it never made it to production-level. There are several things that worked perfectly with Qi, which I never got running the same way in X3. Additionally, the Spirit libraries seem no longer to be in active development. Now, let's get to Boost.Parser: First, I don't want to go into the details of the library, as I think other reviewers did a very good job there. I've been following its evolving since I heard of it in 2022. Back then, I did some test with it and reported some Issues, which got resolved. During the last two years many additional features got added to it. So, Boost.Parser is definitely under active development. Furthermore, the author is an expert for Unicode, which is reflected in the built-in Unicode support of the library. It is written in modern C++ (requires C++17). It is compile-time friendly, supports std::ranges and concepts. It offers an option/abstraction to choose between std::tuples, if needed, or the more flexible hana-implementation. It's syntax is close to Qi, so transition for Qi-users should not be too hard. The documentation contains a lot of examples that help to understand how the library works and how it can be used. Finally, I really like the very easy to use trace-mode. Again, should accept Boost.Parser into Boost? Definitely Yes! Tobias

3 2

Boost.Parser Review
by Phil Endecott 26 Feb '24

26 Feb '24

Boost.Parser Review =================== I've been using Spirit for almost 20 years. It has always been an amazing example of pushing the limits of what is possible in C++, even by the standards of Boost. So it has always left me thinking that we just need to wait a few more years until the language has the few more features needed to smooth over its remaining awkwardness. Now a few years have passed and we have, for example, lambdas, auto, constexpr, concepts. So I was excited to see what improvements Zach's proposed library has over Spirit. For example, when Metaparse was reviewed in 2015, compile-time parsing of BNF was discussed. Perhaps we should be able to write actual BNF in compile-time strings now, rather than re-use C++ operators? And now that we have constexpr, should we be able to convert the production rules to tables at compile time and do proper linear-complexity LALR parsing, rather than top-down? We do now have compile-time regular expression libraries than can do something like this. Initial Reaction ---------------- My first reaction when I looked at the docs was: - I'd like to congratulate Zach on choosing a sensible descriptive name for the library. - The rule syntax looks very much like Spirit. The docs look like the Spirit docs. It's more of an evolution than a revolution. - There's an ugly MACRO to define rules! That doesn't look very 2024 to me. Test Case --------- I decided to try to translate an exiting parser from Spirit v2 (qi) to the new library. It's a parser for latitude-longitude coordinates entered by a human, i.e. it is supposed to try to recognise a range of possible formats. Examples: 12.34 N, 56.78 E 56.78,-12.34 12d 30' n 45d 15' 7" w 12 30 45 N, 45 15 7 W 12d 30m 15s S 50d 59m 59s W There are some subtle issues with this grammar. Note for example that 's' could mean seconds or South. One advantage of Bison is that it gives compile-time diagnostics reporting some of these. Neither Spirit nor the new library can do this. The core of the Spirit code is as follows: (I will link to a .zip with the complete code at the end; I bet the mailing list messes up the long lines.) ///////////////////////////////////// degrees_symbol = lit(UTF8_DEGREES) | no_case[ lit("degrees") | lit("deg") | lit('d') ]; minutes_symbol = lit(UTF8_PRIME) | no_case[ lit('\'') | lit("minutes") | lit("min") | lit('m') ]; seconds_symbol = lit(UTF8_DOUBLE_PRIME) | no_case[ lit('"') | lit("seconds") | lit("sec") | lit('s') ]; uint_0_60 %= uint_ [ _pass = _1 < 60U ]; double_0_60 %= basic_udouble [ _pass = _1 < 60 ]; decimal_degrees %= basic_udouble >> -degrees_symbol; degrees_decimal_minutes = (uint_ >> -degrees_symbol >> double_0_60 >> -minutes_symbol) [ _val = _1 + _2/60.0 ]; degrees_minutes_seconds = (uint_ >> -degrees_symbol >> uint_0_60 >> -minutes_symbol >> double_0_60 >> -seconds_symbol) [ _val = _1 + _2/60.0 + _3/3600.0 ]; degrees %= degrees_minutes_seconds // Longest first. | degrees_decimal_minutes | decimal_degrees; northsouth %= no_case[ char_("ns") ]; eastwest %= no_case[ char_("ew") ]; latitude = (degrees >> northsouth) [( _pass = _1 <= 90, _val = if_else(_2=='S' || _2=='s', -_1, _1) )]; longitude = (degrees >> eastwest) [( _pass = _1 <= 180, _val = if_else(_2=='W' || _2=='w', -_1, _1) )]; signed_degrees %= basic_double >> -degrees_symbol; signed_latitude %= signed_degrees [ _pass = -90 <= _1 && _1 <= 90 ]; signed_longitude %= signed_degrees [ _pass = -180 <= _1 && _1 <= 180 ]; latlon = ((latitude >> longitude) [ _val = construct<g2d::Vector>(_2,_1) ]) | ((longitude >> latitude) [ _val = construct<g2d::Vector>(_1,_2) ]) | ((signed_longitude >> signed_latitude) [ _val = construct<g2d::Vector>(_1,_2) ]); ///////////////////////////////////// The complete Boost.Parser code is as follows: ///////////////////////////////////// #include "boost/parser/parser.hpp" #include <cassert> #include <iostream> #include <optional> #include <string> namespace bp = boost::parser; using namespace boost::hana::literals; namespace g2d { struct Vector { double x, y; }; }; bp::rule<struct uint_0_60, unsigned int> uint_0_60 = "uint_0_60"; bp::rule<struct double_0_60, double> double_0_60 = "double_0_60"; bp::rule<struct degrees_decimal_minutes, double> degrees_decimal_minutes = "degrees_decimal_minutes"; bp::rule<struct degrees_minutes_seconds, double> degrees_minutes_seconds = "degrees_minutes_seconds"; bp::rule<struct degrees, double> degrees = "degrees"; bp::rule<struct latitude, double> latitude = "latitude"; bp::rule<struct longitude, double> longitude = "longitude"; bp::rule<struct signed_latitude, double> signed_latitude = "signed_latitude"; bp::rule<struct signed_longitude, double> signed_longitude = "signed_longitude"; bp::rule<struct latlon, g2d::Vector> latlon = "latlon"; //const auto degrees_symbol = bp::no_case[ bp::lit("degrees") | bp::lit("deg") | bp::lit('d') ]; //const auto minutes_symbol = bp::no_case[ bp::lit('\'') | bp::lit("minutes") | bp::lit("min") | bp::lit('m') ]; //const auto seconds_symbol = bp::no_case[ bp::lit('"') | bp::lit("seconds") | bp::lit("sec") | bp::lit('s') ]; // FIXME those rules don't work and I don't know why. They work if the symbol is // the first alternative; it it's any of the other alternatives the double returned // by e.g. decimal_degrees below is always zero. // Use these instead: const auto degrees_symbol = bp::lit('d'); const auto minutes_symbol = bp::lit('m'); const auto seconds_symbol = bp::lit('s'); // Beware, 's' can also mean south. const auto uint_0_60_def = bp::uint_ [( [](auto ctx) { _pass(ctx) = _attr(ctx) < 60U; _val(ctx) = _attr(ctx); } )]; const auto double_0_60_def = bp::double_ [( [](auto ctx) { _pass(ctx) = _attr(ctx) < 60; _val(ctx) = _attr(ctx); } )]; const auto decimal_degrees = bp::double_ >> -degrees_symbol; const auto degrees_decimal_minutes_def = (bp::uint_ >> -degrees_symbol >> double_0_60 >> -minutes_symbol) [( [](auto ctx) { auto d = _attr(ctx)[0_c]; auto m = _attr(ctx)[1_c]; _val(ctx) = d + m/60.0; } )]; // FIXME this rule matches e.g. 150.5 as 150 .5; we want that input to // be matched by the decimal degrees rule as 150.5. In the qi code, which // has the same fundamental problem, it is avoided because the double_ // parser is configured to reject input with a leading decimal point. // It would be more correct to require that either a degrees symbol or // whitepace or both between the degrees and minutes numbers. That's // a bit complicated because the whitespace is handled by the skipper. // In a bottom-up parser I think the ambiguity is resolved by putting // decimal_degrees first in degrees_def below. That doesn't work for a // top-down parser. // FIXME for similar reasons, "150d 0.5m n" fails to parse, because // the degrees_minutes_seconds rule matches 150,0,.5 and then the next // rule up fails to parse the 'm'. const auto degrees_minutes_seconds_def = (bp::uint_ >> -degrees_symbol >> uint_0_60 >> -minutes_symbol >> double_0_60 >> -seconds_symbol) [( [](auto ctx) { auto d = _attr(ctx)[0_c]; auto m = _attr(ctx)[1_c]; auto s = _attr(ctx)[2_c]; _val(ctx) = d + m/60.0 + s/3600.0; } )]; const auto degrees_def = degrees_minutes_seconds | degrees_decimal_minutes | decimal_degrees; const auto northsouth = bp::no_case[ bp::char_("ns") ]; const auto eastwest = bp::no_case[ bp::char_("ew") ]; const auto latitude_def = (degrees >> northsouth) [( [](auto ctx) { auto d = _attr(ctx)[0_c]; auto ns = _attr(ctx)[1_c]; _pass(ctx) = d <= 90; _val(ctx) = ns=='S' || ns=='s' ? -d : d; } )]; const auto longitude_def = (degrees >> eastwest) [( [](auto ctx) { auto d = _attr(ctx)[0_c]; auto ew = _attr(ctx)[1_c]; _pass(ctx) = d <= 180; _val(ctx) = ew=='W' || ew=='w' ? -d : d; } )]; const auto signed_degrees = bp::double_ >> -degrees_symbol; const auto signed_latitude_def = signed_degrees [( [](auto ctx) { auto d = _attr(ctx); _pass(ctx) = -90 <= d && d <= 90; } )]; const auto signed_longitude_def = signed_degrees [( [](auto ctx) { auto d = _attr(ctx); _pass(ctx) = -180 <= d && d <= 180; } )]; const auto latlon_def = ((latitude >> longitude) [( [](auto ctx) { _val(ctx) = g2d::Vector{_attr(ctx)[1_c], _attr(ctx)[0_c]}; } )] ) | ((longitude >> latitude) [( [](auto ctx) { _val(ctx) = g2d::Vector{_attr(ctx)[0_c], _attr(ctx)[1_c]}; } )] ) | ((signed_longitude >> signed_latitude) [( [](auto ctx) { _val(ctx) = g2d::Vector{_attr(ctx)[0_c], _attr(ctx)[1_c]}; } )] ); BOOST_PARSER_DEFINE_RULES(uint_0_60); BOOST_PARSER_DEFINE_RULES(double_0_60); BOOST_PARSER_DEFINE_RULES(degrees_decimal_minutes); BOOST_PARSER_DEFINE_RULES(degrees_minutes_seconds); BOOST_PARSER_DEFINE_RULES(degrees); BOOST_PARSER_DEFINE_RULES(latitude); BOOST_PARSER_DEFINE_RULES(longitude); BOOST_PARSER_DEFINE_RULES(signed_latitude); BOOST_PARSER_DEFINE_RULES(signed_longitude); BOOST_PARSER_DEFINE_RULES(latlon); static std::optional<g2d::Vector> try_parse_latlon(std::string_view s) { auto input = latlon >> bp::eoi; return parse(s,input, bp::ws|bp::lit(',')); } int main(int argc, const char* argv[]) { assert(argc==2); auto opt_coords = try_parse_latlon(argv[1]); if (!opt_coords) { std::cerr << "parse error\n"; return 1; } else { std::cout << opt_coords->x << " " << opt_coords->y << "\n"; return 0; } } ///////////////////////////////////// That Ugly Macro --------------- bp::rule<struct latitude, double> latitude = "latitude"; const auto latitude_def = (degrees >> northsouth) .... ; BOOST_PARSER_DEFINE_RULES(latitude); Is a macro really the best way to do this? Spirit seems to manage without. Despite having a macro this is still very verbose. I've had to write the name of the rule FIVE times in three lines. Once there is a macro you might as well put everything inside it: BOOST_PARSER_DEFINE_RULE(latitude, double, (degrees >> northsouth) ....); Of course if you need to declare the rules before defining them due to recursion or other forward references you will need separate macros for declaration and definition. These rule declarations seem to need to be at global scope (maybe namespace scope?). Is that fundamental? Can't I put them in a class or a function? Semantic Actions ---------------- In Bison I can write semantic actions like this: { $$ = $1 + $2/60.0; } After expanding the $ variables that gets copied verbatim into the bison output, so it can include any code. Spirit clearly wanted to replicate that sort of functionality, but it pre-dates lambdas, so it includes a lot of amazing functionality that allows me to write semantic actions like: [ _val = _1 + _2/60.0 ] This is nice and concise but its limitation is of course that I cannot write arbitrary code in there. (BTW, are we strictly allowed to use identifiers starting with _ like _val?) What should this look like now that we have lambdas in the language? Of course it's going to be a bit more verbose because of the syntax overhead, but I was hoping that it would be something like this: [ [](auto deg, auto min) { return deg + min/60.0; } ] (Aside: That doesn't actually work because [[ can only appear in attributes even if there is a space, so it needs to be written [( [] ... )]. I did wonder if changing from operator[] to operator() might make sense?) That's longer than before, but I have given meaningful names to the parameters (which I can also do in Bison BTW) and I can include any code. But that's not the syntax that the current proposal needs. It needs this: [( [](auto ctx) { _val(ctx) = _attr(ctx)[0_c] + _attr(ctx)[1_c]; } )] Frankly I think that combines the worst of all the other options and adds some extra new verbosity of its own. One other advantage of having the lambda return a result could be improving how the semantic type (aka attribute type) of a rule is set. For example, if I have the rule degrees >> minutes where degrees and minutes return doubles, the semantic type of the combined rule is something like tuple<double,double>. But I'm going to add a semantic action that adds the two values as shown above, returning one double. If the return value of the semantic action's lambda were used as the semantic type of the rule then we could write: auto rule = (degrees >> minutes) [( [](auto d, auto m) { return d + m/60.0; } )]; and rule would return a double to its parent rule. As it is, the semantic action doesn't change the type and we have to explicitly and verbosely declare the rule as returning a double. Of course the context includes more than just the child rule semantic values and a slot for the result; for example it includes the _pass boolean that I use to clamp the range of values in my example: [( [](auto ctx) { _pass(ctx) = _attr(ctx)[0_c] <= 90; } )]; I suggest that either a special lambda signature is used to indicate that it is a predicate, or an additional "directive" e.g. predicate[ ... ] is added. Compilation Times and Errors ---------------------------- Compilation times for my example were: Boost.Parser: 28.6 s Boost.Spirit: 30.1 s but the grammar is not quite identical, so the small difference is not significant. Code size is somewhat larger for Parser than for Spirit. (g++ 12.2.0, -O3, Linux, aarch64.) I did not particularly notice improved error messages compared to Spirit, though they weren't worse. Consider for example this code from my example: return parse(s, input, bp::ws|bp::lit(',')); Originally I had this: auto skipper = bp::ws | bp::lit(','); return parse(s, input, skipper); But that failed to compile, and I got 15 screenfuls of inpenetrable error messages. I fixed it more-or-less by randomly changing things until it worked. If I now change it back I get only two screenfuls that accurately say that I can't return a bool from a function that's supposed to return an optional, but I still don't know why the return type of parse() changes when I move the declaration of the skipper. So I fear that the idea that compile times and error verbosity are improved compared to Spirit are not borne out. Bugs ---- I found a couple of bugs while writing this review which Zach has resolved. I suspect that this code has not had enough varied use to flush out all the issues. Other Issues ------------ The double_ parser is not configurable in the way that the Spirit double_ parser is. This is problematic; in my example 3e6n means "3 east 6 north", not "3000000 north", so I need a double_ parser that doesn't recognise exponents. I'd also like to ignore values with leading .s, i.e. 10.1 should not match int_ >> double_ as "10 0.1", and I really don't want a hacker to sneak a nan or inf into my code if it recognises those. The docs are not bad and are reminiscent of the Spirit docs. Personally I would prefer to see an example early on that takes a chunk of real BNF and translates it into a parser. I had issues with Apple Clang (15.0.0); it would not compile "#include <boost/parser.hpp>" until I turned off concepts. Has anyone tried with other Clangs? If this is not fixable maybe the library should detect this and use non-concepts mode automatically. Compiling with -Wall resulted in lots of unused parameter warnings. These can be fixed by commenting-out the parameter name, leaving just the type. Boost libraries should compile without warnings, some people use -Werror. Conclusion ---------- I was hoping to find a library that was an improvement on Spirit, but I regret to say that that's not what I've found here. The only notable improvement compared to Spirit.Qi that I've found is that no_case[] is propogated to nested rules, which isn't the case with Qi. Rules themselves are essentially the same as Spirit. The method for defining rules is more verbose and now needs an ugly macro. Semantic actions are less readable. It is possible that there are significant advantages compared to Spirit that I have missed, as a result of having used working Spirit code as my starting point, but I have read the doc's comparison with Spirit page. My conclusion is that this library should not be accepted. If others believe it should be accepted then I feel that should be conditional on many of the issues I've mentioned above being resolved, e.g. unused parameter warnings, configuration of the double_ parser, etc. File containing example: https://chezphil.org/tmp/parser_review.zip Regards, Phil.

4 4

Doxygen+Quickbook and C++20 concepts
by Zach Laine 26 Feb '24

26 Feb '24

I've seen concepts just vanish from Doxygen+Quickbook docs in the past. I thought this was just a limitation. However, looking at the Quickbook docs, I see that there's now a conceptref reference link. So, I put this very simple concept in a header (parser.hpp) to test things: /** \concept non_void */ template<typename T> concept non_void = (!std::same_as<T, void>); Doxygen appears to process it ok, or at least it says in its output that it does. Then I see non_void show up in these files: bin/parser_reference-xml.doxygen bin/parser_reference-xml/index.xml bin/parser_reference-xml/parser_8hpp.xml (I put the concept in this header, parser.hpp) bin/parser_reference-xml/conceptboost_1_1parser_1_1non__void.xml However, when I put [conceptref non_void Non-void.] in a .qbk file, all that shows up in the rendered HTML is "Non-void." (it's not a clickable link). Also, the no_void concept is not in the Doxygen reference for that header. Most frustratingly, concept constraints disappear from constrained templates in the Doxygen reference docs. Is there some special sauce that makes Quickbook+Doxygen process concepts? Is it doing it, but I'm not looking in the right place? Zach

1 0

Review of Parser library ends Wednesday, February 28th.
by Marshall Clow 25 Feb '24

25 Feb '24

So far we’ve received five reviews, and one of them was “docs only”. Keep those reviews coming! — Marshall

1 0

Boost.Parser review by Andrzej
by Andrzej Krzemienski 24 Feb '24

24 Feb '24

Hi, This is another review of Boost.Parser. Usefulness If Boost.Parser is a maintained version of Boost.Spirit that is already a worth goal. If Boost.Parser is a better documented version of Boost.Spirit that is already a gain. Note that the docs for Boost.Spirit X3 are hidden, and I was not aware of its existence until the review of Boost.Parser. I hear that the selling point of this library is Unicode support "through and through". I cannot confirm that it works as advertised, nor benefit from this guarantee, as all my use cases for a parser so far only dealt with the ASCII set. Design Boost.Spirit has a great design, and because Boost.Parser adopts the same design, it must be also good. I would intuitively expect that C++17 offers sufficient number of new features that the design for a parser library would be improved over Boost.Spirits. For instance, I am surprised that we still need to use a macro. Not that I can offer a better alternative. I do not know much about the implementation difficulties. so maybe the macro is the best choice. Wouldn't template explicit specializations do the job? The fact that this library automatically adapts aggregate types as attributes in a Boost.PFR way is really cool. I am convinced that compiler error messages could be better. This can be done by using a combination of static_assert and implementation details SFINAEd away based on the same condition as in static_assert. See https://github.com/tzlaine/parser/issues/56 I am unhappy about the fact that as simple task as parsing a JSON-like array of ints `[1, 2, 3]` into a vector requires me to define a rule. Spirit introduced operator% that doesn't work for empty lists, but doe to its clever attribute conversions (at least in Spirit2), I could define: auto array = '[' > ((int_ % ',') | eps) > ']'; And it would deduce the return attribute alright. But because Boost.Parser wants to be more strict about clever attribute conversions this option is gone, and no alternative is provided other than to declare a rule, which I never needed with Boost.Spirit. See https://github.com/tzlaine/parser/issues/67 I am not comfortable that I have to use the macro BOOST_PARSER_DEFINE_RULES. I would expect that template specializations should give a similar effect. But I do not know how to make it better. But if I have to use a macro, maybe it could offer more, like checking if the rule is compatible with its definition (for earlier bug reporting). I am missing a tool that would give me a compile-time answer * can I pass this attribute to that parser when parsing this type of character? * will my rule with its parser compile for a given input character type? * will my rule with its parser compile for at least one input character type? Documentation To me, the tutorial and overview in the documentation were sufficient to understand the library. But this is because I had learned Boost.Spirit before. If this were my first exposure to "a parser implementation via expression templates", I would be overwhelmed. Even though a lot of effort went into preparing a soft introduction to the subject, the subject is so complicated that it requires a super-gentle introduction. Some things remain underdocumented, like the interface of context. See https://github.com/tzlaine/parser/issues/104 After having stared at the docs for more than a month, I still have trouble finding the table with all the parsers listed. The reference section of documentation is missing details, such as what functions throw, what they expect of their arguments, what they guarantee, what is the exception safety level. For instance, see https://github.com/tzlaine/parser/issues/103 Also, the layout of the reference section looks like it is driven by an auto-generation tool run on the header files. It is not very user friendly. for instance, trying to find the specification of function parse() in https://tzlaine.github.io/parser/doc/html/header/boost/parser/parser_hpp.ht… isn't easy: neither visually (the amount of content is overwhelming) nor with grep-like tool (a lot of things there have "parse" in the name). What is good for header organization is not necessarily good for documentation organization. I am uncomfortable with the responses from the author that the reference section is missing parts, such as concepts, because the documentation toolchain does not support them. This would look like a bad choice of the tool. On the other hand, I do not know of any satisfactory tool for good C++ documentation. My testing I spent like a week trying to compile my parser for a text-based game engine, which was previously compiled with Boost.Spirit v2. Here's a sample file to parse (in Polish): https://raw.githubusercontent.com/akrzemi1/wdungeon/master/wdungeon.plot Here's the original Spirit V2 parser: https://raw.githubusercontent.com/akrzemi1/wdungeon/master/parser.cpp The new parser in BoostParser is included below. I didn't have to use rules in the original version. I am forced to use them in Boost.Spirit. I was not interested in performance testing as my use case is to read the config file upon application startup, so I can afford to wait. I tried the library with the newest versions of MSVC, GCC and Clang. It works in all of them. I filed a number of bug reports, to which Zach has been responding extremely quickly. Thank you! I also appreciate the negative responses, as they indicate that the author has a clear and coherent vision of what he wants the library to be. I recommend accepting the library into Boost. I would also like to thank Zach for writing and sharing this library! Regards, &rzej; ``` namespace parser { using namespace plot2; const auto identifier = bp::lexeme[+(bp::digit | bp::lower | bp::upper | bp::char_('_'))]; const bp::rule<struct cond_tag, std::vector<Variable>> cond = "cond"; const bp::rule<struct set_vars_tag, std::vector<Variable>> set_vars = "set_vars"; const bp::rule<struct choice_tag, Choice> choice = "choice"; const bp::rule<struct continuation_tag, Alternative> continuation = "continuation"; const bp::rule<struct map_tag, std::vector<MapStep>> map = "map"; const bp::rule<struct label_tag, std::string> label = "label"; const bp::rule<struct text_tag, std::string> text = "text"; const bp::rule<struct transition_tag, Transition> transition = "transition"; const bp::rule<struct redirection_tag, Redirection> redirection = "redirection"; const bp::rule<struct comment_tag> comment = "comment"; const bp::rule<struct plot_tag, GamePlot> plot = "plot"; const auto cond_def = ("[" >> ((identifier >> "=" > bp::int_) % ",") > "]") | bp::attr(std::vector<Variable>{}); const auto set_vars_def = ("[" >> ((identifier >> ":=" > bp::int_) % ",") > "]") | bp::attr(std::vector<Variable>{}); auto end_tag = bp::lit("[") >> bp::char_("+!") >> bp::lit("]"); auto label_def = bp::lit("[") >> identifier >> bp::lit("]"); auto text_def = bp::lexeme[+(bp::char_ - ']' - '[')]; auto map_step = bp::lit("^") >> -bp::char_("NESW") >> -(bp::lit(".") >> (+bp::char_("STCLPRXHUVD#"))); auto map_def = bp::lit("[") >> +map_step >> bp::lit("]"); auto redirection_def = +(bp::lit("[->]") >> cond >> (-map) >> label >> set_vars); auto option = bp::lit("[#]") >> cond >> text >> (-map) >> label >> (-text) >> set_vars; auto choice_def = bp::lit("[?]") >> text >> (+option); auto continuation_def = redirection | end_tag | choice; auto transition_def = bp::lit("[##]") > label >> -map >> -text > continuation; auto comment_def = bp::lit("[//]") >> bp::omit[*(bp::char_ - ']' - '[')]; auto plot_def = +transition; BOOST_PARSER_DEFINE_RULES(cond, set_vars, choice, continuation, map, label, text, transition, redirection, comment, plot); } ```

2 3

Parsers vs Unicode
by Arno Schoedl 24 Feb '24

24 Feb '24

Since the reviews of Boost.Parser are currently on, I wanted to share an insight we had at think-cell when working with Boost.Spirit. We have standardized on it for years for all custom parsing needs. Most parsers are small, but some are larger, like Excel expressions. Of course, our input is mostly Unicode, either UTF-8 or UTF-16. Matching Unicode is complex. Comparison by code point is usually not the right thing. Instead, we must normalize, for which we even have various choices of what to accept as equal: https://en.wikipedia.org/wiki/Unicode_equivalence Case-insensitive matching is even more complex, slow, and even language-dependent. Input is often not guaranteed to be valid Unicode. For example, file names on Windows are sequences of 16-bit units, allowing unmatched surrogates, same with input from Win32 edit boxes and file content. But we realized that for almost all grammars we have, all this complexity does not matter. The reserved symbols of most grammars (JSON, XML, C++, URLs, etc.) are pure ASCII. Semantically relevant strings are ASCII as well („EXCEL.EXE“). ASCII can be correctly and quickly matched on a per-code-unit basis. Case-insensitive matching for ASCII is simple and fast. User-defined strings, such as JSON string values, may contain Unicode, but then they usually do not affect parsing decisions. The user may want Unicode validation for these strings, but this can be done by the leaf parser for these strings, rather than for the whole input. Since so much matching is against ASCII, we found it useful to have compile-time known ASCII literals in the parser library. With them, the same grammar can be used for all input encodings. When parsing user-defined strings, they will have the encoding of the input, but that’s fine. Any encoding conversion can be dealt with separately from the parser. Finally, we may want to parse more than just strings. Parsing binary files, or sequences of DNA, should be possible and efficient. Thus I recommend separating Unicode processing from the parser library. The parser library operates on an abstract stream of symbols. For Unicode text these would be code units. It provides the composite parsers such as sequences with and without backtracking, alternatives, Kleene star etc., and leaves the interpretation of the symbols entirely to the leaf parsers, which may or may not care about Unicode. We started modifying Boost.Spirit in this direction, and it serves us well. -- Dr. Arno Schödl CTO schoedl(a)think-cell.com<mailto:schoedl@think-cell.com> | +49 30 6664731-0 We are looking for C++ Developers: https://www.think-cell.com/developers think-cell Software GmbH (Web site<https://www.think-cell.com>) Leipziger Str. 51, 10117 Berlin, Germany Main phone +49 30 6664731-0 | US toll-free +1 800 891 8091 Amtsgericht Berlin-Charlottenburg HRB 180042 Directors: Christoph Hobo, Dr. Arno Schödl Please refer to our privacy policy<https://www.think-cell.com/privacy> on how we protect your personal data.

3 4

Odd build error in 1.85 pre-release - filesystem
by Tom Kent 23 Feb '24

23 Feb '24

When building for windows against the 1.85.0 nightly snapshot, I'm seeing an odd error with no info around it: - type_erasure : building - url : building - wave : building ...patience... ...patience... ...patience... ...patience... ...patience... ...patience... ...patience... [errno 22] failed to scan file '': Invalid argument...found 39744 targets... Upping the verbosity in B2, I was able to find that it appears to happen in filesystem: bind -- <object(c-scanner)@8602>boost\filesystem\detail\type_traits\disjunction.hpp: boost\filesystem\detail\type_traits\disjunction.hpp time -- <object(c-scanner)@8602>boost\filesystem\detail\type_traits\disjunction.hpp: 2024-02-22 07:18:09.000000000 +0000 make -- <object(c-scanner)@8602>boost\filesystem\detail\type_traits\disjunction.hpp make -- <object(c-scanner)@8602>boost\filesystem\detail\type_traits\disjunction.hpp time -- <object(c-scanner)@8602>boost\filesystem\detail\type_traits\disjunction.hpp: unbound made stable <object(c-scanner)@8602>boost\filesystem\detail\type_traits\disjunction.hpp make -- <object(c-scanner)@8602>boost\filesystem\detail\header.hpp make -- <object(c-scanner)@8602>boost\filesystem\detail\header.hpp bind -- [errno 22] failed to scan file '': Invalid argument <object(c-scanner)@8602>boost\filesystem\detail\header.hpp: boost\filesystem\detail\header.hpp time -- <object(c-scanner)@8602>boost\filesystem\detail\header.hpp: 2024-02-22 07:18:09.000000000 +0000 make -- <object(c-scanner)@8602>boost\filesystem\detail\header.hpp make -- <object(c-scanner)@8602>boost\filesystem\detail\header.hpp time -- <object(c-scanner)@8602>boost\filesystem\detail\header.hpp: unbound made stable <object(c-scanner)@8602>boost\filesystem\detail\header.hpp Anyone have ideas on what this can be? Why it doesn't show up more like a normal error? Thanks, Tom

3 4

2023 Transparency Report
by Louis Tatta 21 Feb '24

21 Feb '24

Hello, Louis Tatta here, CEO of The C++ Alliance, Inc, a registered 501(c)(3) non-profit organization dedicated to the support of C++. This is our 2023 transparency report regarding our charitable work for the Boost C++ Library Collection. First, some background on our operations. The C++ Alliance seeks out the highly talented and experienced C++ experts and hires them, usually full-time, so they can focus completely on their open-source projects. Our Staff Engineers maintain existing Boost libraries, write new Boost libraries, and contribute to other Boost projects. We employ IT experts full-time to maintain and improve the infrastructure which supports Boost, including the legacy web server, the Drone continuous integration servers, the scripts used to deploy GitHub Actions for Boost repositories, and the scripts which publish the Boost release. In addition, we provide on-demand technical support services for Boost authors and maintainers who have infrastructure related problems. The Boost Mailing List continues to be the premier place for high-quality discussion of the Boost libraries and tangential C++ Standards related topics. The C++ Alliance supports the use of the mailing lists going forward. We are upgrading it to the latest Mailman version, and building an optional web-based front-end allowing interaction using only a browser. We continue to operate the Official C++ Language Slack Workspace (https://cpp.al/slack) which hosts the most popular interactive discussions regarding the Boost libraries. The C++ Alliance sponsors a paid plan to provide full history, video and audio conferences, collaboration tools, and unlimited document storage for seventeen dedicated Boost library channels and one main Boost discussion channel. Our largest project for 2023 is the continuation of work on the new Boost website. The new site is a C++ social media portal with rich support for user-generated content, and a powerful back-end which has visibility into the contributions made on GitHub and the release process. This allows us to deliver an elevated user experience with the hopes of attracting fresh talent to Boost. Also,note that the graphics on the website are hand-drawn by our contract artist and reflect our level of commitment to ensure that Boost, to put it simply, looks good. In 2023 there were a total of four Boost Formal Reviews. One of the reviewed libraries is authored by a C++ Alliance Staff Engineer. Three of the reviews were managed by C++ Alliance team members. Out of a total of twenty-eight submitted reviews for the year, twelve were from C++ Alliance team members. Last year we increased our efforts to build Boost’s social media presence. There were a total of twelve messages from the @Boost_Libraries X (formerly Twitter) account, all submitted by C++ Alliance team members. Three of them contained artwork from Bob Ostrom commissioned by us. Messages containing images get three times more engagement than text-only messages. We believe that the X platform has unique strategic value for informing newer generations about the Boost value proposition. A total of $1,768,000 was spent on Boost-related contributions, broken down thusly (and rounded to the nearest thousand): Staff Engineers Compensation $1,240,000 Website Software Development $570,000 Server Hosting $62,000 C++ Slack Workspace $96,000 Conference Sponsorship $10,000 Conference Attendance $10,000 During 2023 we employed a total of 12 individuals to contribute to Boost. Here is a high-level summary of accomplishments: Sam Darwin (Chief Technical Officer) * Boost website maintenance and administration * Boost per-pull-request documentation previews * Boost Release Process development, maintenance, and administration * Boost Mailman services maintenance and upgrade * Boost GitHub Actions self-hosted runner project development * Boost Drone service administration and maintenance * New Boost website deployment, administration, and development Dmitry Arkhipov (Staff Engineer) * Boost.JSON maintenance Alan de Freitas (Staff Engineer) * Boost.URL maintenance * Mr. Docs project management (https://mrdocs.com) * GitHub actions support scripts for Boost CI (https://alandefreitas.github.io/cpp-actions/cpp-actions/index.html) Christian Mazakas (Staff Engineer) * Boost.Unordered evolution project * Boost.Buffers development (new library) * Boost.Http.Proto, Boost.Http.Io development (new libraries) * Boost.Websocket.Proto, Boost.Websocket.Io development (new libraries) Krystian Stasiowski (Staff Engineer) * Boost.StaticString maintenance * Mr. Docs Lead engineer (https://mrdocs.com/) * Clang/LLVM contributions Peter Turcan (Senior Technical Writer) * Boost User Guide development (new documentation) * Boost Contributor Guide (new documentation) * Boost Formal Reviews (new documentation) Matt Borland (Staff Engineer) * Boost.Charconv (new, accepted library) Ruben Perez * Boost.MySQL maintenance (new, accepted library) * User Guide, Contributor Guide contribution (new documentation) Mohammad Nejati (Staff Engineer) * Boost website full-text search feature * Boost.Beast maintenance Fernando Pelliccioni (Staff Engineer) * Mr. Docs development (https://mrdocs.com/) Spencer Strickland (Senior Web Developer) * New website front-end and scripting Klemens Morgenstern (Staff Engineer) * Boost.Beast maintenance * Boost.Cobalt (new, accepted library) Joaquin M Lopez Munoz (Staff Engineer) * Boost.Unordered evolution project lead * Boost Contributor Guide contributions (new documentation) Our sources of funding are secure and we look forward to continuing our charitable contributions throughout this decade and beyond. It is an honor and a pleasure to support the Boost C++ Library collection. Thank You Louis Tatta

5 4

Reminder: Boost 1.85.0 will be closing for new libraries and breaking changes THIS WEDNESDAY
by Marshall Clow 20 Feb '24

20 Feb '24

As always, look at the calendar at https://www.boost.org/development/ — Marshall

2 1

Review of Parser library begins today
by Marshall Clow 19 Feb '24

19 Feb '24

The review of Zach Laine’s proposed Boost.Parser library begins today and will end on February 28th. From the introduction page of the documentation: Boost.Parser is a parser combinator library. That is, it consists of a set of low-level primitive parsers, and operations that can be used to combine those parsers into more complicated parsers. There are primitive parsers that parse epsilon (the empty string), chars, ints, floats, etc. There are operations which combine parsers to create new parsers. For instance, the Kleene star operation takes an existing parser p and creates a new parser that matches zero or more occurrences of whatever p matches. Both callable objects and operator overloads are used for the combining operations. For instance, operator*() is used for Kleene star, and you can also write repeat(n)[p] to create a parser for exactly n repetitions of p. Boost.Parser also tries to accommodate the multiple ways that people often want to get a parse result out of their parsing code. Some parsing may best be done by returning an object that represents the result of the parse. Other parsing may best be done by filling in a preexisting data structure. Yet other parsing may best be done by parsing small sections of a large document, and reporting the results of subparsers as they are finished, via callbacks. Boost.Parser accommodates all these ways of working, and even makes it possible to do callback-based or non-callback-based parsing without rewriting any code (except by changing the top-level call from parse() to callback_parse()). All of Boost.Parser's public interfaces are sentinel- and range-friendly, just like the interfaces in std::ranges. Boost.Parser is Unicode-aware through and through. When you parse ranges of char, Boost.Parser does not assume any particular encoding — not Unicode or any other encoding. Parsing of inputs other than plain chars assumes that the input is Unicode. In the Unicode-aware code paths, all parsing is done by matching code points. This means that you can feed UTF-8 strings into Boost.Parser, both as input and within your parser, and the right sort of matching occurs. For instance, if your parser is trying to match repetitions of the char '\xcc' (which is a lead byte from a UTF-8 sequence, and so is malformed UTF-8 if not followed by an appropriate UTF-8 code unit), it will not match the start of "\xcc\x80" (UTF-8 for the code point U+0300). Boost.Parser knows that the matching must be whole-code-point, and so it interprets the char '\xcc' as the code point U+00CC. Error reporting is important to get right, and it is important to make errors easy to understand, especially for end-users. Boost.Parser produces runtime parse error messages that are very similar to the diagnostics that you get when compiling with GCC and Clang (it even supports warnings that don't fail the parse). The exact token associated with a diagnostic can be reported to the user, with the containing line quoted, and with a marker pointing right at the token. Boost.Parser takes care of this for you; your parser does not need to include any special code to make this happen. Of course, you can also replace the error handler entirely, if it doesn't fit your needs. Debugging complex parsers can be a real nightmare. Boost.Parser makes it trivial to get a trace of your entire parse, with easy-to-read (and very verbose) indications of where each part of the trace is within the parse, the state of values produced by the parse, etc. Again, you don't need to write any code to make this happen — you just pass a parameter to parse(). Github: https://github.com/tzlaine/parser Docs https://tzlaine.github.io/parser — Marshall

1 0

Re: [boost] Should boost::core::string_view be made public?
by g.peterhoff＠t-online.de 18 Feb '24

18 Feb '24

Have you come to a conclusion how this should be handled (in the future)? The problem is basically that there are different implementations for string_view. I don't know why it was done this way. Presumably it's because various boost libraries want to be independent of others, so that some things are implemented anew each time (within the library) instead of using existing libraries. This will also be due to the fact that boost is not atomistic enough, so that large libraries might have to be included/used, although only a fraction of the functionality is needed. My suggestion: - Throw out boost::utility::string_view - Make boost::core::detail::string_view public, just like all other backports in boost::core. - Check if there are other multiple implementations. If so, pull them out into separate small boost libraries. (For databases, this would be called normalization, but it must not be over-normalized). regards Gero

5 4

Potential Launch of Boost Website: Request for Final Feedback
by Louis Tatta 17 Feb '24

17 Feb '24

Louis here from the C++ Alliance. With the potential launch of the new Boost website on the horizon this week, we're making a final call for your feedback. Your insights a few months ago were incredibly helpful, and as we approach the launch, we'd value your final review. If you have a moment to look over the site again and note any issues or suggestions, it would be of great help. Feedback can be submitted on our GitHub issues page: https://github.com/cppalliance/temp-site/issues. Thank you for your ongoing support and contributions to the Boost community. Looking forward to your feedback. Best regards, Louis C++ Alliance

18 79

Re: [boost] New Website Repositories
by Glen Fernandes 16 Feb '24

16 Feb '24

On 2024-02-16, Vinnie Falco wrote: > On Fri, Feb 16, 2024 at 12:33, Glen Fernandes wrote: > > If you want to follow the tradition of source files, the easiest > > convention to follow is to state that your files, e.g. > > > >  > > We can do that, or alternatively is it possible to just plop a LICENSE > file at the root of the repository? I would prefer both (thanks). Glen

1 0