July 2026 - Boost - lists.boost.org

[boost][int128] Formal Review Begins Today (July 22-July 31)
by Arnaud Becheler 02 Aug '26

02 Aug '26

Dear Boost Community, I am very happy to open the Formal Review period for Candidate Boost.Int128 authored by Matt Borland, running from today, July 22nd to July 31st 2026. Int128 is a portable C++14 implementation of signed and unsigned 128-bit integers. It has no dependencies, is header-only, and can be consumed as a module in C++20. You can find the library and its documentation here: - https://github.com/cppalliance/int128/tree/boost_review - https://develop.int128.cpp.al/overview.html I could make examples work in Compiler Explorer: https://godbolt.org/z/5aM6K9b4r Although possibly not faithful to Matt's implementation, this CE link will be handy if you are in a rush but want to play with the library. Candidate Boost.Int128 serves as a practical solution to the partial (resp. absent) support of 128-bit integers by gcc/clang (resp. msvc), and as an alternative to projects with a heavy dependency footprint. For example Boost.Multiprecision offers 128-bit integers but drags 25 Boost modules which may not be acceptable when only a single type is required. We can expect this new lightweight library to interest anyone manipulating integers beyond the 64bit numeric range, for simple problems like when summing many 64-bits integers in an accumulator, computing a*b/c where the intermediate product overflows 64 bits, or in complex fields like cryptography, hashing, random number generation, precision arithmetic... Note: Due to the Boost release cycle, the master branch is frozen on all Boost projects. This had the inconvenient effect of preventing Matt from operating a cross-repo PR to enable GPU support with Boost.Charconv. Due to the lack of a practical solution, the CI on master will remain red until 1.92 ships. We kindly ask reviewers to focus on the boost_review branch. As always, we welcome all reviews, from quick impressions to detailed analysis. Your feedback helps ensure that the library meets Boost's high standards for correctness, performance, documentation, and design. If you’re interested in contributing a review, please post to the Boost mailing list during the review period. In your review please state whether you recommend to REJECT or ACCEPT the library into Boost, and whether you suggest any conditions for acceptance. Other questions you might want to answer in your review are: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With what compiler? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problems tackled by the library? Thank you for your time, Have a wonderful week, Arnaud Becheler, Review Manager Boost.Int128

11 20

[release] 1.92.0 post-beta merges: master branch is open
by Ion Gaztañaga 31 Jul '26

31 Jul '26

The master branch is is now open for post-beta merges, but only as described in the Post-Beta Merge Policy. See <https://github.com/boostorg/wiki/wiki/Releases%3A-Beta-Merge-Policy>: Summary: Master open for documentation updates. Other changes by permission of a release manager. Boost Calendar with the release schedule: https://www.boost.org/calendar/ Thanks, -- The Boost Release Team

8 17

Fw: Question about Boost.Asio async_send_to returning error 101 (Network unreachable)
by THANH VAN NGUYEN/LGEDV CONNECTIVITY SERVICE TEAM 31 Jul '26

31 Jul '26

________________________________ From: THANH VAN NGUYEN/LGEDV CONNECTIVITY SERVICE TEAM <thanh13.nguyen(a)lge.com> Sent: Friday, July 31, 2026 1:40 PM To: boost(a)lists.boost.org <boost(a)lists.boost.org> Subject: Fw: Question about Boost.Asio async_send_to returning error 101 (Network unreachable) ________________________________ From: THANH VAN NGUYEN/LGEDV CONNECTIVITY SERVICE TEAM Sent: Friday, July 31, 2026 1:35 PM To: boost(a)lists.boost.org <boost(a)lists.boost.org> Subject: Question about Boost.Asio async_send_to returning error 101 (Network unreachable) Hello Boost Team, I am investigating an issue related to Boost.Asio UDP communication and would appreciate your guidance. We have a UDP listener/sender implementation using boost::asio::ip::udp::socket. In our field logs, the application successfully receives UDP packets, validates them, generates an ACK message, and then calls async_send_to() to send the ACK back to the sender. However, the send callback reports: Plain Text 1 Sent ACK message for contextID: xxx error with err_code: 101 Show more lines Error code 101 corresponds to: Plain Text 1 Network unreachable Show more lines Relevant code: C++ mSocket.async_send_to( net::buffer(&ack[0], ack.size()), mSenderEndpoint, [uto err_code, auto bytes_sent { if ((!err_code) && (bytes_sent > 0U)) { LOGI("Sent ACK success"); } else { LOGE("Send ACK failed, err_code=%d", err_code.value()); } }); Additional observations: * UDP packets are successfully received through async_receive_from(). * mSenderEndpoint is obtained from the received packet. * Message validation succeeds before sending ACK. * The socket is opened and bound using IPv6: C++ mSocket.open(udp::v6(), ec); mSocket.bind(udp::endpoint(udp::v6(), port), ec); My questions are: 1. Under what conditions can async_send_to() return error 101 even though async_receive_from() successfully received packets from the same endpoint? 2. Could this be related to IPv4/IPv6 endpoint mismatch, routing changes, or interface availability during asynchronous transmission? 3. Is there any recommended way to obtain more detailed diagnostics from Boost.Asio for this situation? Any insight would be greatly appreciated. Thank you for your support. Best regards, Thanh Van Nguyen LG Electronics

1 0

Boost.Asio async_send_to() returns error 101 (Network unreachable) after successful async_receive_from()
by thanh13.nguyen＠lge.com 31 Jul '26

31 Jul '26

Hello Boost Users, I am investigating an issue related to Boost.Asio UDP communication and would appreciate any insight. We have a UDP listener implemented with Boost.Asio. The application successfully receives UDP trigger packets via async_receive_from(), verifies the payload, builds an ACK message, and immediately sends the ACK back using async_send_to(). However, the send callback reports: C++1Sent ACK message ... error with err_code: 101Show more lines Error 101 corresponds to: Plain Text1ENETUNREACH (Network unreachable)2`Show more lines Simplified code: C++1mSocket.async_receive_from(2 net::buffer(mData, max_length),3 mSenderEndpoint,4 auto ec, int bytes_recvd {5 if (!ec && bytes_recvd > 0) {6 // Verify trigger7 doSend(ack);8 }9 doReceive();10 });11 12mSocket.async_send_to(13 net::buffer(&ack[0], ack.size()),14 mSenderEndpoint,15 auto err_code, auto bytes_sent {16 if (err_code) {17 std::cout << "send failed: "18 << err_code.value()19 << std::endl;20 }21 });22 Show more lines Observations: UDP trigger packets are received successfully. Message verification succeeds. ACK generation succeeds. async_send_to() fails immediately with err_code = 101. The same endpoint obtained from async_receive_from() is used for ACK transmission. Socket is opened and bound as IPv6: C++1mSocket.open(udp::v6(), ec);2mSocket.bind(udp::endpoint(udp::v6(), port), ec);Show more lines This occurs sporadically after a vehicle wakeup scenario. It looks as if the receive path is already available, but the transmit route is not yet ready. My questions are: Under what conditions can async_send_to() return ENETUNREACH even though packets were successfully received from the same endpoint moments before? Could this be related to IPv4/IPv6 endpoint handling, routing table readiness, or network interface state changes? Is there any Boost.Asio-specific recommendation for handling such transient network conditions? Any suggestions or similar experiences would be greatly appreciated. Thank you. Best regards, Thanh Van Nguyen LG Electronics

1 0

[int128] Some thoughts
by Jamie Allsop 27 Jul '26

27 Jul '26

Hi Matt, Thanks for writing this library - it looks very useful and certainly fills a hole. This is not a review, just some thoughts from a quick look at the docs and source code. From the docs all your use cases are relevant to us, and in particular the third for financial computing. We do exactly that. Currently we build on gcc and use `__int128` with a few workarounds. In general that's been fine. Replacing with `int128` would likely bring us little value at this stage but certainly I could see good value for any new projects and especially for those looking for portability. Your benchmark results were encouraging and might tempt me to consider using this in the future as a result. I would remark I see the comparison with the abseil 128 numbers interesting WRT addition and signed vs unsigned. It looks like your implementation is optimised for unsigned whereas as abseil favours signed? FWIW I'd see more value in optimising mathematical operations for signed integers. If you are using unsigned ints for that you probably have a design issue. In looking over the code (briefly) I got to wondering if you could apply similar principles to a 256 bit type. For us we always need 128 and 256 bit integer types (we do a lot of EVM based work which uses 256 bit ints). Currently we are forced to use boost.multiprecision for 256 bit ints which has all the issues you mention and would be a very obvious replacement for us. Like many who need int128 today, they already have a workaround, but nothing useful exists for 256 bit numbers which are very common in the crypto and blockchain world. Would it be challenging to develop a similar library for 256 bit support given your experience of developing this 128 library? As I said I see value in Int128, but it is more a nice-to-have for us since we have something lightweight already (__int128) but would dearly love to see a solid Int256 library that perhaps compliments Int128. If I get more time later in the week I might try and do a proper review. Jamie

2 1

[release] Boost 1.92.0 Beta 1
by Ion Gaztañaga 22 Jul '26

22 Jul '26

Boost 1.92.0 beta 1 is now available at: https://archives.boost.io/beta/1.92.0.beta1/ The SHA256 checksums are as follows: 005f4903695cce4382340ea57dd53bd1f0762927de28c9fa265f6ea2c7c1ad3f boost_1_92_0_b1.zip 11f8f032a73cfd91899f170341578cabc040c4473e95a056cdc919c90778fa05 boost_1_92_0_b1.tar.bz2 290472960719ccc487e2f91ebc952c86b6d0244a9a4ec36a943d8f7485b29b3b boost_1_92_0_b1.7z 585e0a028cc3f1f7711842b7cbfbb5faece2f243ef57ffe7fb846e9b61e2faa5 boost_1_92_0_b1.tar.gz For details of what's in the release, see the changelog available at: https://www.boost.org/releases/1.92.0.beta1. Boost Calendar with the release schedule: https://www.boost.org/calendar/ Please download the beta, give it a try, and report any problems you encounter. Thanks, -- The Boost Release Team

4 4

Fwd: [release] 1.92.0 post-beta merges: master branch is open
by René Ferdinand Rivera Morell 18 Jul '26

18 Jul '26

Failed to send this to the correct reply email.. ---------- Forwarded message --------- From: René Ferdinand Rivera Morell <grafikrobot(a)gmail.com> Date: Tue, Jul 14, 2026 at 10:29 AM Subject: Re: [release] 1.92.0 post-beta merges: master branch is open To: Ion Gaztañaga <igaztanaga(a)gmail.com> On Tue, Jul 14, 2026 at 10:26 AM Ion Gaztañaga <igaztanaga(a)gmail.com> wrote: > El 14/07/2026 a las 17:19, Ion Gaztañaga via Boost escribió: > > El 14/07/2026 a las 16:18, René Ferdinand Rivera Morell via Boost > escribió: > >> Can I merge the latest B2 version 5.5.2? Changes in it from the current > >> 5.5.1 are https://github.com/bfgroup/b2/releases/tag/5.5.2 > > > > Go ahead as this fixes a regression. > > > > Ion > > Sorry, I misunderstood the regression issue, but 5.5.2 fixes other issues. > Rene, > are you going to fix the regression and create 5.5.3 before merging? > Yes, going to fix the issue Alexander mentioned and make a 5.5.3. I'll ask again after I have the new patch release tested, published, merged to develop, and ready for master. -- -- René Ferdinand Rivera Morell -- Don't Assume Anything -- No Supongas Nada -- Robot Dreams - http://robot-dreams.net -- -- René Ferdinand Rivera Morell -- Don't Assume Anything -- No Supongas Nada -- Robot Dreams - http://robot-dreams.net

2 3

Capy/Corosio Review Extended to Sunday July 11
by Jeff Garland 16 Jul '26

16 Jul '26

Hi Everyone - I appreciate all the reviews up to now, but as previously mentioned there's a lot of surface area to cover -- so we'll be extending the review for a few more days. Thanks again, Jeff

1 1

[release] Boost 1.92.0 Beta 1 Release Candidate 1 is available
by Ion Gaztañaga 12 Jul '26

12 Jul '26

Available at: <https://archives.boost.io/beta/1.92.0.beta1/source/> The SHA256 checksums are as follows: 11f8f032a73cfd91899f170341578cabc040c4473e95a056cdc919c90778fa05 boost_1_92_0_b1_rc1.tar.bz2 585e0a028cc3f1f7711842b7cbfbb5faece2f243ef57ffe7fb846e9b61e2faa5 boost_1_92_0_b1_rc1.tar.gz 290472960719ccc487e2f91ebc952c86b6d0244a9a4ec36a943d8f7485b29b3b boost_1_92_0_b1_rc1.7z 005f4903695cce4382340ea57dd53bd1f0762927de28c9fa265f6ea2c7c1ad3f boost_1_92_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

8 16

Boost Review for Capy and Corosio - June 23 to July 7th
by Jeff Garland 09 Jul '26

09 Jul '26

Dear Boost Community: The Boost Formal Review of the *Corosio* and *Capy* libraries will begin on *June 23, 2026* and will conclude on *July 7, 2026*. I'm Jeff Garland and I'll be the review manager. I'd like to thank Vinnie for inviting me to maintain the continuity from Boost.Asio and I'll apologize now for the late notice. Since this is a two library review the period is somewhat extended from normal. In fact my personal pre-review indicates we will likely need an extension due to the size of the libraries -- I'll work with the review wizards on that. Capy Capy is a coroutine foundation library providing task types, execution contexts, executors, asynchronous synchronization primitives, buffer abstractions, and coroutine composition facilities. It serves as the execution and asynchronous programming substrate upon which Corosio is built. Repository: - Capy GitHub Repository <https://github.com/cppalliance/capy?utm_source=chatgpt.com> - docs <https://develop.capy.cpp.al/capy/index.html> Corosio Corosio is a coroutine-native asynchronous I/O library for C++20. It provides networking and I/O facilities designed specifically for coroutines, with awaitable operations, executor affinity, cancellation support, and cross-platform implementations based on IOCP, epoll, and kqueue. Repository: - Corosio GitHub Repository <https://github.com/cppalliance/corosio?utm_source=chatgpt.com> - docs <https://develop.corosio.cpp.al/corosio/index.html> Review Questions Potential reviewers are encouraged to consider the following questions: 1. What is your evaluation of the usefulness of the libraries? 2. What is your evaluation of the design? 3. What is your evaluation of the implementation? 4. What is your evaluation of the documentation? 5. Have you used either or both libraries? What was your experience? 6. Are the libraries ready for inclusion in Boost? 7. If not, what changes would you recommend before acceptance? 8. Do the libraries fit well within the existing Boost ecosystem? 9. Are there API, naming, usability, extensibility, or implementation concerns that should be addressed? How to Participate Please post your review to the Boost Developers mailing list. Reviews from both experienced Boost contributors and first-time reviewers are encouraged. Reports based on real-world usage, experimentation, code inspection, and documentation review are all valuable contributions. At the conclusion of the review period, the review manager will consider all feedback and determine whether the libraries should be accepted into Boost. We look forward to your participation in this review.

19 72