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

Two mqtt libraries
by Robert Ramey 03 Oct '24

03 Oct '24

I've been contacted by my friend and sometime collaborator Takatoshi Kondo regarding his submission of a boost library: https://github.com/redboltz/async_mqtt. It has received two endorsements. He has asked me to be review manager and I'm inclined to accept this request as he was very helpful to me during the refinement of the boost serialization library. There is also mqtt client library that is proposed to the Boost. https://github.com/mireo/async-mqtt5 It also has endorsements and a review manager. A cursory examination of the git hub pages suggest considerable overlap between the two submissions. In general, boost has discouraged the acceptance of multiple libraries with this much overlap - and for good reason. An accepted library often becomes the canonical implementation in large parts of the C++ world. Having two high quality libraries that do almost the same thing is not where we would like to be. I would like to propose that we review both libraries simultaneously in order to try to reach a consensus as to which, if either we want to accept. I know this is a difficult task, but I think it is important that we do this. It's going to be tough to reject a well written library because a better one has been accepted. But it would be worse to reject a well written library merely because another one was submitted first. Normally I don't participate as a review manager as I'm pretty bogged down in Boost stuff as it is. But I'm willing to make an exception in this case due to the importance of this case and my strong personal ties to Takatoshi. BTW - who is the review wizard these days? I presume that he will be the one making the decision about this. Robert Ramey

10 17

Boost Asset Stewardship Review begins 09/03 (Updated)
by Glen Fernandes 18 Sep '24

18 Sep '24

Update: The Boost Foundation proposal mentioned in the original announcement has been published. The Boost Foundation proposal is attached to this email: BoostFoundationStewardshipProposal.pdf A link to the above will also be available in the review commencement email that will be posted on 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 The original announcement email included an attachment of the above: https://lists.boost.org/Archives/boost/2024/08/257569.php - Glen

19 47

Domain Transfer Update
by Kristen Shaker 13 Sep '24

13 Sep '24

Hello, I wanted to give everyone an update regarding what is happening with the boost.org domain. We are working with the lawyer representing the Dawes estate to transfer control. However, Beman Dawes was the only one with the credentials, and the transfer process without them is onerous. It may take many months. We intend to continue to provide updates. Warm Regards, Kristen

10 11

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

[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