- Boost - lists.boost.org

[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

[release] 1.92.0 closed for Beta
by Ion Gaztañaga 09 Jul '26

09 Jul '26

The master branch is now closed for all changes except by permission for the Beta release. Also, remember to add your libraries' changes to the release notes at: https://github.com/boostorg/website-v2-docs/blob/develop/release-notes/boos… Calendar is here: https://www.boost.org/calendar/ Thanks, -- The Boost Release Team

1 0

[icl] Request to merge PR#54
by Joaquin M López Muñoz 08 Jul '26

08 Jul '26

Hi, In its version 22, libc++ introduced changes to their implementation of non-heterogeneous lookup for associative containers that break some assumptions Boost.ICL relies on: https://github.com/llvm/llvm-project/issues/183189 Turns out lookup for associative containers has been poorly specified since forever. I submitted an issue to the WG21 committee positing that a resolution should be adopted that (among other things) would make Boost.ICL assumptions correct: https://cplusplus.github.io/LWG/issue4572 In the latest meeting in Brno, however, the committee decided against that resolution with the result that, pending an upcoming reformulation of the affected part of the standard, Boost.ICL will be officially relying on undefined behavior. I've written a PR to circumvent this problem: https://github.com/boostorg/icl/pull/54 that relies on heterogeneous lookup (well defined and compatible with the asumptions made by Boost.ICL). I contacted the library maintainer some weeks ago but received no answer, so I'm asking here for this PR to be merged before Boost 1.92, since without it, Boost.ICL is currently broken for libc++ v22. FWIW, some users of Boost.ICL are already applying this fix to their local deployments of Boost: https://github.com/azahar-emu/ext-boost/commit/6a85c3100499e886e11c87a5c210… Another contributor has posted a different PR with the same goal: https://github.com/boostorg/icl/pull/57 My analisys is that this PR is not as comprehensive as PR#54 (it fails to cover intervals of type right_open_interval and related), plus its performance is probably slightly inferior, so I still recommend that PR#54 be used instead. Thank you, Joaquín M López Muñoz

3 4

[capy] Andrzej's feedback
by Andrzej Krzemienski 08 Jul '26

08 Jul '26

Hi Everyone, I do not feel qualified in the domain of asynchronous I/O to provide a responsible review. But let me share some observations instead. I would like to thank the Capy/Corosio team for developing and sharing these libraries. This is a huge scope, a huge effort, a great lot of moving parts and details to tackle. I am not even sure how this can be reviewed with the level of scrutiny that is required. I appreciate the unprecedented level of the design rationale. The library comes not only with sources, tests and library documentation, but also with lots of documents presenting rationale for every tiny decision. The contribution of this library is not only the code that users can use, but also the accumulated (and shared) knowledge that can be used by anyone, for writing their own I/O framework and avoiding the past mistakes. This alone builds my trust in the authors and the quality of the library. The value proposition of Capy and Corosio is not only in providing a faster and easier to use alternative to ASIO. It is also the responsiveness of the authors and openness for contribution. It gives me confidence that if I encounter some problems with the library in the future, they will be solved in a predictable way. Now, the concerns. A couple of things in the IoAwaitable protocol give discomfort: 1. Having to use thread_local storage 2. Having to use the double-call syntax. 3. Having to use pass they stop_token via await_ready (and therefore risk UB when stop_token is queried before the first suspend). Ideally, these things should not be present in a protocol. However, it seems impossible to provide any alternative design, with coroutines as its basic vehicle, that would have fewer problems like these. What can we conclude from this? It looks like C++ coroutines are not well suited for I/O-like flows with environment propagation. You can do it *somehow*: just pass all you need in the coroutine's function parameter list, but it is not ergonomic or type-safe. I think the review of Capy may be exposing a design flaw in coroutines. If the goal of Capy is to provide the best third-party library asynchronous-I/O coroutine implementation, then the current design may indeed be the best (as in "no better design can be thought of"). But if the goal is to aim at standardization, I do not think that such unsafe design would work. The action would rather be, "fix coroutines in the language". This makes me think that coroutines in C++ may be a dead end. This would be consistent with some other observations: scarce adoption in the community and WG21 itself choosing to use a different model for asynchronous flows. One could question one design choice in Capy: why go with coroutines when you have to fight an uphill battle with the language? But then, given that it outperforms ASIO and std::execution, it has clearly earned its place. It surely deserves its place in Boost as "the best you can do with coroutines for I/O". But if I were to consider switching to a different library for async I/O I would also consider/evaluate non-coroutine alternatives. On the usage of error_code and reporting failures. The library doesn't give me a clear picture on how it handles and how I should handle the non-clear-sky situations. For things that represent obvious disappointments -- broken connection, problems on the wire, not enough memory to process a request -- it sometimes returns an error_code and sometimes throws an exception. It looks like the division is: * for things happening on the wire, or in the system's native part of the I/O implementation, use error_code * for problems with resources in the implementation of the library throw exceptions. But then also, the library returns error_codes for situations that are not errors by any measure: for situations that I desire: * Successfully receiving full stream content. * Stopping the running process upon my request. The only model for this that I can adapt is that the contract of stream interaction is similar to the interaction with a human postman: * They can deliver you a parcel * But they can also tell you "I lost your parcel", or "while obtaining the parcel I noticed that the box is half-open", or "I had a car accident, and couldn't deliver your parcel" That is, your success is having had a meeting with the postman and chatted with them and maybe also having obtained the parcel. In that model not receiving a parcel is not an error. This makes sense for the interaction with a single stream, but breaks for the next layer: 1. when you have to interact with two streams at once: pull_from, push_to. 2. when you have "algorithms" such as when_any, when you have to nominate the first successful task. But in the postman model nearly everything is successful. Having read the stream status is success. In the case of push_to/pull_from, you might be interested in knowing which of the two streams was the cause of disappointment. But the interface does not let you get this information. Interaction with two postmen would require two statuses. While the contract of `stream.read_some` is "I promise you nothing else than to inform you what happened", it is not clear to me what the contract of pull_from is. Is it: a) I promise to pump the data from one stream to the other. We will call it a contract violation if I fail. OR b) I will just issue some stream instructions in sequence and tell you what the readouts of controls are. My having told you the readout is already a success; you interpret what this means for you. In this case I do not buy the "ASIO got that right" argument. If ASIO is also unclear about the contract, then ASIO got that wrong also. There are a lot of libraries that are popular, contribute to the success of servers that employ them, but that get their contracts wrong. I am bringing the contract aspect, because I know that the authors of Capy care deeply about this level of clarity. A number of libraries were accepted to Boost while having a muddy contract, and this did not seem to be a show-stopper. My observations are based on reading the documentation and the implementation of some parts of Capy and Corosio, running toy examples and discussing the design aspects with the authors. Disclaimer: I am affiliated with the C++ Alliance, and have occasionally contributed to Capy. Regards, &rzej;

7 15

Master branch closes for the 1.92 beta TOMORROW
by Ion Gaztañaga 07 Jul '26

07 Jul '26

Calendar is here: https://www.boost.org/calendar/ — The release managers

1 0