- Boost - lists.boost.org

shout out to Gennaro Prota
by Robert Ramey 07 Aug '26

07 Aug '26

A few weeks ago Gennaro took over the maintenance of the Boost Serialization Library. I've been following his work on addressing a large backlog of issues and PRs. The reason there's such a backlog is that many/most of them are quite subtle and many are edge cases. My handling of these was to spend a little time on them and conclude - whoops this is non-trivial - I'll have to address it later when I have time. My assessment hasn't changed. But I'm really impressed with how many he has addressed in a serious and definitive manner. I'm very optimistic about the future of the Boost Serializaton library. I never imaged that it wouldn't be standardized by now. Now I see why - Here's to another 25 years of the Boost Serialization library. Congratulations to Gennaro for taking this on and being so successful at it. Robert Ramey

4 3

[boost][int128] Formal Review Result
by Arnaud Becheler 05 Aug '26

05 Aug '26

Dear Boost Community, As Review Manager for Candidate Boost.Int128, I have carefully reviewed and incorporated the community's feedback from July 22–31. I decided to ACCEPT Boost.Int128 into Boost. The library's well-defined scope, clear design, its excellent documentation, its proven track record in the wild (including in Boost.Decimal and in production codebases on multiple platforms, tested on bare metal), the author's responsiveness throughout the review, and the fact that all review issues/PRs have been tracked with the "Boost Review" label, resolved (see: https://github.com/cppalliance/int128/pulls?q=is%3Apr+is%3Aclosed+label%3A%… ), and merged on develop convinced me to accept the library. Every reviewer who cast a formal vote recommended acceptance, and the only conditional verdict rested on bugs that Matt resolved (and one feature request he could not: https://github.com/cppalliance/int128/issues/485 ). As for the details: ACCEPT (7) Rainer Deyke (July 27) (Undisclosed) John Maddock (July 27) (Undisclosed) Christopher Kormanyos (July 27) (collaborator with the author; not C++ Alliance) Pavel Pavlov (July 28) (Undisclosed) Peter Turcan (July 28) (C++ Alliance) Jamie Allsop (August 1) (Undisclosed) Nigel Stewart (August 1) (Undisclosed) ACCEPT CONDITIONALLY (1) Guillaume Dua (July 28–30) (Undisclosed) COMMENTS / NOT A FORMAL REVIEW Andrzej Krzemienski (August 2): on library-vs-builtin type semantics. Various Reddit reviewers (eisenwave/WG21, James20k, MarekKnapek, and others) contributed substantive technical feedback without a formal verdict. Jarod on French Discord: contributed a bug report without a formal verdict. NOTE: I also note that several reviewers and commenters appreciated that the library was available through a single-header aggregated file included by Compiler Explorer, making it extremely easy to experiment with, stress the implementation and review. I sincerely think this should become the norm, not the exception for future (small-ish?) libraries. The cost of aggregating the headers in CI is trivial and the benefit shows up in the numerous latent bugs surfaced by reviewers. CONCLUSION AND THANKS: Congratulations to Matt Borland on an excellent contribution, and my sincere thanks to everyone who took the time to review, test and debate. I must insist that identifying all those bugs early will make life infinitely easier for users and maintainers. Your time and effort are greatly appreciated. Have a wonderful week, Best wishes, Arnaud Becheler, Review Manager for Boost.Int128 ... and hopeful future Review Manager for Boost.256 ? ;)

3 2

[release] Master branch is closed for the 1.92.0 release
by Ion Gaztañaga 05 Aug '26

05 Aug '26

Master is closed for all changes. See the release schedule at http://www.boost.org/calendar — The release managers

1 0

[multi] Multi Mini Review Begins Thursday
by Matt Borland 03 Aug '26

03 Aug '26

Hello, This is an announcement that the mini review of Multi [1] will begin on Thursday (August 6) and run through next Tuesday (August 11). The focus of this review will be the documentation, as that was identified as the weak point in the review earlier this year. This is the last scheduled review, so streak of reviews is nearly over. Thank you all for your participation. Matt Multi Review Manager [1] https://github.com/correaa/boost-multi

1 0

[boost][int128] Formal Review Is Now Closed
by Arnaud Becheler 03 Aug '26

03 Aug '26

Good morning Boost Community, After a small extension over the weekend to allow potential reviewers to chime in, I am happy to declare that the Formal Review of Candidate Boost.Int128 is now closed! I will summarize the exchanges, count the votes and issue a statement in the next few days. I want to thank everyone who took part in the review and discussions, both on this mailing list and on other networks (Slack, Reddit, LinkedIn, Discord...): this was very helpful for both the Review Manager and the author. It is quite formidable to see what an open-source community can put together! Reviews like this are the closest thing C++ has to a sports team, and that was a very clean game :) Have a great week, Best wishes, Arnaud Becheler, Review Manager

1 0

[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