[boost][int128] Formal Review Begins Today (July 22-July 31)
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
Two questions that I have been asked in different forums already that are worth sharing with the list: "What's the point when _BitInt is coming?" _BitInt is coming perhaps in C++29. _BitInt(N) is also optional for all N > 64 so there are no guarantees you will have _BitInt(128) on any given platform. This requires only C++14 and is tested all the way back to GCC 5, Clang 5, MSVC 14.1. "also doesn't gcc/clang support __in128? and msvc has std::_Int128?" GCC/Clang support __int128 only on 64-bit platforms and also not on Windows. MSVC has std::_int128, but it is completely undocumented. Basically if you need to write portable code that requires 128-bit integers this will work regardless of toolchain and architecture today. Matt
I've been using this `int128` lib for quite a while, way before `Decimal` was added to boost. At first, I wanted to use boost multiprecision for int128 support, but due to my specific use case it wasn't acceptable. In short, I wanted something that works as close as possible to regular int64_t/uint64_t but for 128-bit numbers (eg overflows/casting produce similar results, vars are 16 bytes in size etc). I tried google's abseil (`absl::int128`/`absl::uint128` from `absl/numeric/int128.h`), `std::_Unsigned128`/`std::_Signed128` for msvc compiler (from their `__msvc_int128.hpp`), `__int128` in gcc/clang and some other libs. But at the end I had painful spaghetti mix of ifdefs and workarounds: in some cases `__in128` (or some operations with it) aren't available for clang/gcc, in some cases implementation of some functions clearly was inferior in one lib vs some other. I had some questions on [multiprecision github](https://github.com/boostorg/multiprecision/issues/666), that's where I found out about int128 lib. Initially, I added to the mix of code I had for 128bit math, but eventually I removed all of that and I use `boost::int128` directly now. I've been using it for a year for msvc/clang/gcc on win64/win32, gcc/clang on linux.
Thank you, Pavel, for your thoughtful and precise review, much appreciated! Would you be open to emitting a formal ACCEPTED, REJECTED or CONDITIONALLY ACCEPTED (with your conditions)? That helps the Review Manager assess the general feedback and community needs by counting each opinion and making a decision about the library's acceptance. I naturally remind each future reviewers to formulate those formal opinions and disclose affiliation (if possible). Thank you all for your participation in this important moment of the Boost life cycle (a potential newborn!) Best wishes, Arnaud Becheler, Review Manager for Candidate Boost.Int128
Yes, I accept. On Mon, 27 Jul 2026 at 15:34, Arnaud Becheler <arnaud.becheler@gmail.com> wrote:
Thank you, Pavel, for your thoughtful and precise review, much appreciated!
Would you be open to emitting a formal ACCEPTED, REJECTED or CONDITIONALLY ACCEPTED (with your conditions)? That helps the Review Manager assess the general feedback and community needs by counting each opinion and making a decision about the library's acceptance.
I naturally remind each future reviewers to formulate those formal opinions and disclose affiliation (if possible). Thank you all for your participation in this important moment of the Boost life cycle (a potential newborn!)
Best wishes, Arnaud Becheler, Review Manager for Candidate Boost.Int128
First off many thanks to Matt for contributing this library, this is a fairly quick "drive by" review, hopefully others will delve deeper, although as noted below that's hardly needed, given that the interface is pretty much fixed ahead of time.
Other questions you might want to answer in your review are: - What is your evaluation of the design?
It's an integer, there's not much to discuss to be honest. Indeed for an integer type, it's almost overly-feature complete, but complaining about that is churlish to be honest. One random question: I wonder if any consideration was given to making integers with checked or saturating operations separate types? I appreciate that this is NOT the way the standard has gone, but it looks useful to me, maybe that's a whole other library though? Likewise while we're on the subject of providing a poly-filler, some of the algorithms (<numeric> for example) could usefully be extended to all the integer types (as per C++26), but again that looks like another library to me. While on the subject of completeness, I'm pleased to see device support (CUDA/Sycl) straight out of the box. This is not necessarily a question for Matt, but I'm wondering if there might be any good example algorithms that would make use of this and provide some kind of benchmark and/or indication of when using parallel computing is actually useful?
- What is your evaluation of the implementation? Only a very quick look, but Matt knows what he's doing, and this library has been used out in the wild for a while now. - What is your evaluation of the documentation? Excellent and very easy to read. - What is your evaluation of the potential usefulness of the library?
What can I say, in some ways this is a poly-filler library which may not be needed... or may be essential depending on your platform/compiler. In any case I vote to ACCEPT this library. I hope others will take the time to look through this too. Best, John Maddock.
On Monday, July 27th, 2026 at 8:49 AM, John Maddock via Boost <boost@lists.boost.org> wrote:
First off many thanks to Matt for contributing this library, this is a fairly quick "drive by" review, hopefully others will delve deeper, although as noted below that's hardly needed, given that the interface is pretty much fixed ahead of time.
Other questions you might want to answer in your review are: - What is your evaluation of the design?
It's an integer, there's not much to discuss to be honest. Indeed for an integer type, it's almost overly-feature complete, but complaining about that is churlish to be honest.
One random question: I wonder if any consideration was given to making integers with checked or saturating operations separate types? I appreciate that this is NOT the way the standard has gone, but it looks useful to me, maybe that's a whole other library though? Likewise while we're on the subject of providing a poly-filler, some of the algorithms (<numeric> for example) could usefully be extended to all the integer types (as per C++26), but again that looks like another library to me.
I have had the same thoughts, and that library can be found here: https://github.com/cppalliance/safe_numbers. As always, I would appreciate hearing your thoughts on that one.
While on the subject of completeness, I'm pleased to see device support (CUDA/Sycl) straight out of the box. This is not necessarily a question for Matt, but I'm wondering if there might be any good example algorithms that would make use of this and provide some kind of benchmark and/or indication of when using parallel computing is actually useful?
Yes, I can improve this section. The initial reason for GPU support was to get Boost.Decimal working on GPU (CUDA support will ship in the next Boost release in a few weeks). CUDA somewhat recently added a 128-bit integer support to their platform so they must have some level of demand. SYCL and spir64 have no such support.
- What is your evaluation of the implementation? Only a very quick look, but Matt knows what he's doing, and this library has been used out in the wild for a while now. - What is your evaluation of the documentation? Excellent and very easy to read. - What is your evaluation of the potential usefulness of the library?
What can I say, in some ways this is a poly-filler library which may not be needed... or may be essential depending on your platform/compiler.
In any case I vote to ACCEPT this library.
I hope others will take the time to look through this too.
Best, John Maddock.
Thank you for taking the time to review John. Matt
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. Here is my review of theproposed Boost.Int128. Thank you Matt for writing theproposed Int128 and Arnaud formanaging the review. **I recommend the proposed Int128to be unconditionally ACCEPTEDto Boost.** The proposed Boost.Int128 fillsan asymmetric gap in popular,existing compiler implementations.Today's patchwork support for128-bit integers is incomplete,and architecturally incompatibleamong platforms. Yet the datatype is very frequently used inengineering, scientific andmathematical domains. A fundamental component thatis widely used is not uniformlyunavailable at the moment.This may evolve in the future,but the gap at the moment existsand will cause discrepanciesfor years. The proposed Boost.Int128 evensout this asymmetry and providesa uniform, high performanceinterface to 128-bit integraltypes. The types attempt tobehave properly in the senseof intuitively mimicking thebehaviors of built-in integraltypes. This is done in a drop-in,convenient, header-only fashion. Evaluation of the design? The design is clear. It works.Care has been taken to separateindividual library parts forinclusion as needed. Platform-dependent optimizations(and these are definitely present)are well-separated and transparentto the consumer. The result is the intent - 128-bitsigned and unsigned integral typesthat behave as similarly as possibleto the behaviors of built-inintegral types. Evaluation of the implementation? The implementation is lucidlyclear. The component separationof the headers makes sense withinthe context of existing std libcomponents such as the types,charconv, functions, etc. Evaluation of the documentation? The documentation is complete,clear and is more than sufficientfor me. Evaluation of the usefulness? For me this lib is essential. This proposed library providesa uniform, portable, performant,platform-independent impl of(u)int128_t. It is designed to fill in onecrass, long-time, existing,uneven gap among popularcompiler impls. It does thisexcellently by providingcross-platform access to 128-bitintegral types. These types arepopular and used in numerousdomains. The library is in a relativelycomplete state. I feel confidentusing it and shipping it.As the library evolves, surelyedge-case weaknesses will bediscovered and corrected.But at the moment, it'sready-to-go. Use the library, effort?Knowledgeable about the domain? I've used the library activelyand deeply since its beginnings.I use it to fuzz and performstress-test comparisons withsome of my own separate,independent big integerimplementations. It is alsoinstrumental in the impl. ofBoost.Decimal, where edge-caseweaknesses have already beenfound and corrected. Specifically for this review,I set up a fun and educationalbenchmark: Boost.Int128 versuscomputer algebra, computingmillions of 128-bit prime numbers.This has stress-exercised binaryoperations, masking, shiftingand made heavy use of powm. As a final step I ported a fewsimple exercises to a bare-metal32-bit microcontroller systemhaving no OS and no inputoutput. What I tested workedfine.
I consider myself to be highlyknowledgeable in the domain. Further comments? There is already one 256-bitquery, and more or extendedqueries might follow. I suspect,however, that this library ispurposefully for 128-bit typesexclusively. Further typeswill probably need separateproposals. - Christopher Disclaimer: I'm multi-timecollaborator with the author.I am *not* affiliated withthe C++ Alliance. I havea few commits in Int128, butby no means consider myselfa co-author. On Wednesday, July 22, 2026 at 01:40:03 PM GMT+2, Arnaud Becheler via Boost <boost@lists.boost.org> wrote: 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 _______________________________________________ Boost mailing list -- boost@lists.boost.org To unsubscribe send an email to boost-leave@lists.boost.org https://lists.boost.org/mailman3/lists/boost.lists.boost.org/ Archived at: https://lists.boost.org/archives/list/boost@lists.boost.org/message/GLZALH3W...
Further comments? There is already one 256-bitquery, and more or extendedqueries might follow. I suspect,however, that this library ispurposefully for 128-bit typesexclusively. Further typeswill probably need separateproposals.
The 256-bit question also came up on the Reddit. I would certainly propose a separate int256 lib rather than starting to collect these specific fixed width ints into a boost.not-quite-multiprecision.
- Christopher Disclaimer: I'm multi-timecollaborator with the author.I am *not* affiliated withthe C++ Alliance. I havea few commits in Int128, butby no means consider myselfa co-author.
Thank you for taking the time to review and exercise the library. Matt
Arnaud, Thanks for taking on the review manager role, and thanks to Matt for submitting this library! Here is my review of the Boost.Int128 documentation. For the record I am the technical writer for the CppAlliance. Overall, the documentation is complete and well structured. What follows are the nits that could be addressed to improve the user experience. *Introduction* Try to avoid awkward punctuation in the introduction (parentheses, i.e., etc.) - these are reading obstacles, an introduction should be fluid. Consider changing: Boost.Int128 is a portable implementation of a signed, and an unsigned 128-bit integer and related functionality (i.e. <bit>, <iostream>, etc). Importantly, on all platforms, the sizeof the types provided in this library are exactly 128-bits. to something like: *Boost.Int128 is a fully portable implementation of signed and unsigned 128-bit integers. The library supports a robust range of related functionality such as <bit>, <numeric>, <ios>, <string> and <iostream>. On all platforms, the size of the 128 bit types provided are exactly 128-bits.* Perhaps add a paragraph to get some more numbers in the mix: *For comparison, a 64-bit unsigned integer maximum value is 18,446,744,073,709,551,615. The maximum value for a 128-bit unsigned integer is 340,282,366,920,938,463,463,374,607,431,768,211,455. For signed integers, the maxima are half of these. These enormous numbers are used in scientific and financial computing, though perhaps more often as 128-bit values holding identifiers, addresses and bit masks.* This paragraph is a little awkward, haven't you already said the library is header-only - no need to say "The library is also available as a single header here." Consider changing: The library is header-only, has no dependencies, and requires only C++14. The library is also available as a single header here. When using C++20 or newer, the library can be consumed as a module import boost.int128. to two short paragraphs: *The library is header-only, has no dependencies, and requires C++14 or later. When using C++20 or later, the library can optionally be imported as a module: import boost.int128.* *Boost.Int128 is available here[LINK].* *Getting Started* Would have liked the "Getting Started" section to end with a "hello world" example - possibly 3 super short examples (one each for Windows, Linux, Macos), perhaps even just adding two numbers together and printing the result. *Pretty Printers*Would prefer to see the pretty printers section follow the examples. and not precede it. Seemed jarring to go from getting started straight into printing, without any working code in between. *Examples*Good to see the Examples well commented and with Expected Output - would have liked to see an introductory sentence/para to each example highlighting anything special or of note about the code, and/or the use case to which it applies. *Directory Structure*- some Headers entries are not links; can they be made links? *Formatting Support*The order of fmt, format reversed in the left-hand TOC compared to the text. *Boost.Random SupportComparison to Boost.Multiprecision*These sections should include links to the named library - does boost:random[] work as an auto link? *Configuration Macros*Is the use of these macros trivial, or would the more complex one's benefit from a short example? *Benchmarks* Bit of a nit but the long numbers are awkward to compare quickly. For example, 9932867 10242720 They are easier to compare (no counting of digits) as: 9,832,867 10,242,720 That's my 2c. The documentation is above par and is no obstacle to the library being ACCEPTED. - best Peter Turcan On Mon, Jul 27, 2026 at 7:20 AM Matt Borland via Boost < boost@lists.boost.org> wrote:
Further comments? There is already one 256-bitquery, and more or extendedqueries might follow. I suspect,however, that this library ispurposefully for 128-bit typesexclusively. Further typeswill probably need separateproposals.
The 256-bit question also came up on the Reddit. I would certainly propose a separate int256 lib rather than starting to collect these specific fixed width ints into a boost.not-quite-multiprecision.
- Christopher Disclaimer: I'm multi-timecollaborator with the author.I am *not* affiliated withthe C++ Alliance. I havea few commits in Int128, butby no means consider myselfa co-author.
Thank you for taking the time to review and exercise the library.
Matt_______________________________________________ Boost mailing list -- boost@lists.boost.org To unsubscribe send an email to boost-leave@lists.boost.org https://lists.boost.org/mailman3/lists/boost.lists.boost.org/ Archived at: https://lists.boost.org/archives/list/boost@lists.boost.org/message/CQ4LJID7...
Dear Boost Community, If you have not produced a Boost.Int128 Formal Review yet, I would like to encourage you to do so quickly, as we are nearing closing day. You may ask me for a review period extension. To help you experiment faster, a Compiler Explorer link including the latest develop fixes can be found here: https://godbolt.org/z/axWzhKTvn Also, Guillaume Dua kindly produced a Formal Review with the verdict: CONDITIONALLY ACCEPT. The reviewer made several points, quoted here:
Design: Beside caveats described hereafter, the API feels intuitive and simple for common use-cases. constexpr (especially for C++14) and NTTP support are expected yet great additions too. Documentation: https://develop.int128.cpp.al/ looks way better than what I'm used to with other Boost libraries (before its modernisation). The search bar and preview are convenient/efficient. Testing: Looks very decent. Accessibility: The standalone header working on godbolt (compilation time) is great to experiment fast.
The reviewer raised several bugs/issues that Matt is addressing, that I summarize here: 1) Inconsistent conversion to bool 2) Preprocessor-directive side effects (headers disable -Wsign-conversion for the rest of the TU) 3) saturating_mul may have a wrong branch 4) BOOST_INT128_NO_BUILTIN_INT128 gets ignored if/when BOOST_HAS_INT128 is defined 5) boost::random::traits::make_unsigned<int128_t>::type result in int128_t 6) Ambiguous overload resolutions: __int128 vs. uint128_t 7) boost::int128::uint128_t feels odd to write -> uint128 type nested in a int128 namespace. The details of this great review, including numerous snippets and Compiler Explorer reproducers are available in an issue opened by the reviewer: https://github.com/cppalliance/int128/issues/476 Guillaume had already raised several bugs about Int128 before his formal review, and Matt fixed them. I would like to thank Guillaume and all of previous reviewers for taking the time to review Candidate Boost.Int128 and for making the Boost ecosystem better, stronger, safer. Best wishes, Arnaud Becheler, Review Manager for Candidate Boost.Int128
Here is my formal review of the proposed int128 library. There's not really much to review. It's a portable int128_t type that somehow manages to outperform native __int128. Assuming that the implementation makes good on the promises in the documentation (and I have no reason to suspect that it doesn't), there is barely any room for criticism. The one thing that bothers me is that all of the std-equivalent functions are placed in the int128 namespace, which makes it harder to write generic code. Instead of this: auto f(auto i) { return std::has_single_bit(i); } I now have to write this instead: auto f(auto i) { using namespace std; return has_single_bit(i); // use ADL } This is annoying. I wish there was a function somewhere like this: // not in some_namespace to prevent infinite recursion namespace some_namespace_detail { auto impl_has_single_bit(auto i) { using namespace std; return has_single_bit(i); } } namespace some_namespace { auto has_single_bit(auto i) { return some_namespace_detail::impl_has_single_bit(i); } } That way I could write my function like this, without using a using directive: auto f(auto i) { return some_namespace::has_single_bit(i); } However, that seems to be outside the scope of boost::int128. On 7/22/26 13:37, Arnaud Becheler via Boost wrote:
Other questions you might want to answer in your review are: - What is your evaluation of the design?
I see no room for criticism. Aside from the basic (u)int128_t types, the library seems to offer everything needed for interoperability, up to the limits of the language itself.
- What is your evaluation of the implementation?
I haven't looked at the source code, but if the benchmarks are correct, then I am impressed.
- What is your evaluation of the documentation?
Readable, well organized, and it looks both complete and correct. I see no room for criticism.
- What is your evaluation of the potential usefulness of the library?
Fairly useful, and definitely worth having. While I found myself wishing for a good (ideally native) 128 bit integer type from time to time, I can't say that I ever really needed one.
- Did you try to use the library?
No.
- How much effort did you put into your evaluation? A glance? A quick reading? In-depth study?
Maybe an hour of work, most of it spent browsing the documentation.
- Are you knowledgeable about the problems tackled by the library?
Yes. My verdict: ACCEPT unconditionally. -- Rainer Deyke - rainerd@eldwood.com
The one thing that bothers me is that all of the std-equivalent functions are placed in the int128 namespace, which makes it harder to write generic code. Instead of this:
auto f(auto i) { return std::has_single_bit(i); }
I now have to write this instead:
auto f(auto i) { using namespace std; return has_single_bit(i); // use ADL }
This is annoying. I wish there was a function somewhere like this:
// not in some_namespace to prevent infinite recursion namespace some_namespace_detail {
auto impl_has_single_bit(auto i) { using namespace std; return has_single_bit(i); }
}
namespace some_namespace {
auto has_single_bit(auto i) { return some_namespace_detail::impl_has_single_bit(i); }
}
That way I could write my function like this, without using a using directive:
auto f(auto i) { return some_namespace::has_single_bit(i); }
However, that seems to be outside the scope of boost::int128.
Perhaps one day a proposal like P4188 (wg21.link/p4188) will allow us to do so inside of std. I agree it is rather annoying. Boost.Math has BOOST_MATH_STD_INCLUDE which expands to basically all of the cmath functions which is a bit better than having to write a bunch of using std::whatever; at the top of a function.
My verdict: ACCEPT unconditionally.
Thank you for the review Rainer! Matt
I tried a few things with boost::int128. Including something (sort of) fun: 34 factorial. I like this, pushing past the limits of uint64_t. (Proper review to follow) - Nigel 34! = *295232799039604140847618609643520000000* std::cerr << "34! = " << fac<boost::int128::uint128_t>(34) << std::endl; Python (for a second opinion):
math.factorial(34) *295232799039604140847618609643520000000*
Hi Arnaud, A very late and very short review. On 22/07/2026 12:37, Arnaud Becheler via Boost wrote:
Other questions you might want to answer in your review are: - What is your evaluation of the design?
It looks good, solves a genuine problem and we would probably update our codebase to use it.
- What is your evaluation of the implementation?
I only took a brief look but it seemed to be of high quality, written by someone who knows the subject matter.
- What is your evaluation of the documentation?
The documentation was comprehensive and informative.
- What is your evaluation of the potential usefulness of the library?
It solves a real use case in several domains that the docs list at the start. We are in a least one of those.
- Did you try to use the library? With what compiler? Did you have any problems?
I did but as we use a pattern like this in our code: enum class big_quantity : int128_type { none = std::numeric_limits<int128_type>::max() }; which of course doesn't work with this type so it was not useful. However I could potentially create a derived class that has the same benefit possibly (I want a named integer type) but then I'd have to rewire a bunch of other stuff. I did enough to see that we could potentially have this work but it was too much effort for this review. I was using gcc15.3 btw.
- How much effort did you put into your evaluation? A glance? A quick reading? In-depth study?
A couple hours only. It's a 128bit integer.
- Are you knowledgeable about the problems tackled by the library?
We use __int128 in our codebase for exactly the reasons listed in the rationale but sadly this would not be a trivial drop-in replacement but I could see how it might be useful if we needed it. We do need an int256 type that's lightweight and performant and if we had that I could see us using this as well as for that it would be worth working out the (extensive) reworking of the enum pattern. That said I think this library is a valuable addition (but int256 would be even more useful ;-)) so I vote to ACCEPT the library. Jamie
- Did you try to use the library? With what compiler? Did you have any problems?
I did but as we use a pattern like this in our code:
enum class big_quantity : int128_type { none = std::numeric_limits<int128_type>::max() };
which of course doesn't work with this type so it was not useful. However I could potentially create a derived class that has the same benefit possibly (I want a named integer type) but then I'd have to rewire a bunch of other stuff. I did enough to see that we could potentially have this work but it was too much effort for this review.
I have not tried this, but for whatever it's worth Claude (Opus 5 Max) recommends the following: Works everywhere including MSVC and SYCL device: struct big_quantity { boost::int128::int128 value {}; static const big_quantity none; }; constexpr big_quantity big_quantity::none {std::numeric_limits<boost::int128::int128>::max()}; Verified usable in constant expressions. You supply operator==/operator!= yourself pre-C++20. What you lose versus enum class is switch exhaustiveness and implicit-conversion blocking.
We use __int128 in our codebase for exactly the reasons listed in the rationale but sadly this would not be a trivial drop-in replacement but I could see how it might be useful if we needed it. We do need an int256 type that's lightweight and performant and if we had that I could see us using this as well as for that it would be worth working out the (extensive) reworking of the enum pattern.
That said I think this library is a valuable addition (but int256 would be even more useful ;-)) so I vote to ACCEPT the library. Jamie
int256 has come up a number of times during this review period so I will probably work on that over the next few months. Shouldn't be a large leap from what is already in here. Thank you for taking the time to review! Matt
sob., 1 sie 2026 o 03:09 Jamie Allsop via Boost <boost@lists.boost.org> napisał(a):
Hi Arnaud,
A very late and very short review.
On 22/07/2026 12:37, Arnaud Becheler via Boost wrote:
Other questions you might want to answer in your review are: - What is your evaluation of the design?
It looks good, solves a genuine problem and we would probably update our codebase to use it.
- What is your evaluation of the implementation?
I only took a brief look but it seemed to be of high quality, written by someone who knows the subject matter.
- What is your evaluation of the documentation?
The documentation was comprehensive and informative.
- What is your evaluation of the potential usefulness of the library?
It solves a real use case in several domains that the docs list at the start. We are in a least one of those.
- Did you try to use the library? With what compiler? Did you have any problems?
I did but as we use a pattern like this in our code:
enum class big_quantity : int128_type { none = std::numeric_limits<int128_type>::max() };
which of course doesn't work with this type so it was not useful.
This is interesting. It shows why a library solution will never be a full substitute for a built-in type. For a similar reason, it would be a bad idea for this library implementation to fall back to an alias on a built-in type on platforms where it is available, as then users would not be able to reliably depend on being able to derive from the type to make extensions. Regards, &rzej; However I could potentially create a derived class that has the same
benefit possibly (I want a named integer type) but then I'd have to rewire a bunch of other stuff. I did enough to see that we could potentially have this work but it was too much effort for this review.
I was using gcc15.3 btw.
- How much effort did you put into your evaluation? A glance? A quick reading? In-depth study?
A couple hours only. It's a 128bit integer.
- Are you knowledgeable about the problems tackled by the library?
We use __int128 in our codebase for exactly the reasons listed in the rationale but sadly this would not be a trivial drop-in replacement but I could see how it might be useful if we needed it. We do need an int256 type that's lightweight and performant and if we had that I could see us using this as well as for that it would be worth working out the (extensive) reworking of the enum pattern.
That said I think this library is a valuable addition (but int256 would be even more useful ;-)) so I vote to ACCEPT the library. Jamie
_______________________________________________ Boost mailing list -- boost@lists.boost.org To unsubscribe send an email to boost-leave@lists.boost.org https://lists.boost.org/mailman3/lists/boost.lists.boost.org/ Archived at: https://lists.boost.org/archives/list/boost@lists.boost.org/message/VYUXW3KW...
This is interesting. It shows why a library solution will never be a full substitute for a built-in type. For a similar reason, it would be a bad idea for this library implementation to fall back to an alias on a built-in type on platforms where it is available, as then users would not be able to reliably depend on being able to derive from the type to make extensions.
Regards, &rzej;
The types in the library are never an alias to other types; they are always a struct of two 64-bit words. When available (and performant) the built-ins will be leveraged for implementation of operations e.g. division can become static_cast<builtin_u128>(lib_lhs) / static_cast<builtin_u128>(lib_rhs). Matt
Thank you Arnaud for coordinating this review process. Boost.Int128 is appealing for certain applications that require larger magnitude integers than provided by int32_t or int64_t. I have sometimes used multiprecision libraries in the past, but fixed-size storage is often preferred for array storage and performance reasons. I do also think Boost.Int128 could form a basis for eventual formal C++ language support, although perhaps fairly niche. (C++ is already large and multi-paradigm, so why not?) The portability of Boost.Int128 is very appealing, especially across gcc, clang and microsoft toolchains. It's super-nice that std::format works, for example. I have spent a few hours of my after work time reading parts of the documentation and applying this to some old PhD code of mine. I've had success with a constexpr (wasn't before) table-based factorial implementation supporting uint32_t, uint64_t and Boost.Int128. In the course of that I also came across some of my own bugs from years ago which were easily clarified and resolved with the help of Boost.Int128. (I can now run in any of the three modes to confirm that 64-bit is sufficient or not, nice) One minor quibble I had with the documentation. The examples section has a prominent section for libfmt, but I felt that std::format should be at least as prominent. I was of course reassured to find std::format mentioned in the reference section, and it worked just fine, so all good there. A minor gap I came across was C++23 std::byteswap and related endian support. Less of a practical concern nowadays, but it would be nice for Boost.Int128 to "just work" there too. It seems necessary to use BOOST_INT128_UINT128_C macro to initialise a std::array<boost::int128::uint128_t, 35>. A C++ language constraint? Certainly could be me doing it "wrong". (But it works) I recommend to ACCEPT Boost.Int128, it is a worthwhile addition to the boost toolbox, and documented and implemented to a high standard. - What is your evaluation of the design?
Provides a native-like type for both signed and unsigned 128 bit integers. Seems like the obvious and correct approach. My array of uint64_t would be twice as much RAM, but still a single malloc.
- What is your evaluation of the implementation?
Well structured. Didn't have any trouble enabling std::format, iostream or literals.
- What is your evaluation of the documentation?
Nice modern formatting and detailed enough presentation. Tone is appropriate, not quirky or overly opinionated.
- What is your evaluation of the potential usefulness of the library?
Useful to me, depending on the problem domain. Would have been all over it as a PhD student, for sure.
- Did you try to use the library? With what compiler? Did you have any problems?
I used gcc 13.3.0 with -std=c++23 and -Wall flags. I refactored some old code to extend it for 128 bit arithmetic. My quick ad-hoc testing showed the same expected output for both 64-bit and 128-bit modes.
- How much effort did you put into your evaluation?
A few hours of trying things and thinking about use cases. It ticked all the more obvious boxes, in terms of day-to-day work. Such as "will spdlog freak out? No, we're good". - Are you knowledgeable about the problems tackled by the library?
Part of my PhD was concerned with evaluating large exponents and factorials. My recollection is that I needed to be careful to multiply and divide in a sensible order. I don't think I exceeded what can be done with 64-bits, but I was aware of the potential for trouble. My first thought with Boost.Int128 was to build a "really, really big" 3D minecraft world. Turns out that's billions times larger than the observable real-world universe, at 1m granularity. As a reference, Minecraft worlds are "only" 60,000km wide horizontally. Large magnitudes can be challenging in geospatial domains. 64 bits seems sufficient to zoom (google maps style) all the way from planetary to atomic scale. Usually smaller integers are fine, but having 128 or even 256 within easier reach, even better.
One minor quibble I had with the documentation. The examples section has a prominent section for libfmt, but I felt that std::format should be at least as prominent. I was of course reassured to find std::format mentioned in the reference section, and it worked just fine, so all good there.
I can add that. Right now it says above the example you can replace all the calls to fmt:: with std:: in the example, but clearly it could be better.
A minor gap I came across was C++23 std::byteswap and related endian support. Less of a practical concern nowadays, but it would be nice for Boost.Int128 to "just work" there too.
byteswap is currently available: https://develop.int128.cpp.al/bit.html#byteswap. As for the endian functions that would be a good addition.
It seems necessary to use BOOST_INT128_UINT128_C macro to initialise a std::array<boost::int128::uint128_t, 35>. A C++ language constraint? Certainly could be me doing it "wrong". (But it works)
BOOST_INT128_UINT128_C is offered for two reasons. First, is that it is analogous to UINT64_C, etc. that people are already used to. Second, BOOST_INT128_INT128_C can be used to initialize INT128_MIN whereas a literal cannot.
I recommend to ACCEPT Boost.Int128, it is a worthwhile addition to the boost toolbox, and documented and implemented to a high standard.
Thank you for your review! Matt
participants (11)
-
Andrzej Krzemienski -
Arnaud Becheler -
Christopher Kormanyos -
Jamie Allsop -
John Maddock -
Matt Borland -
Nigel Stewart -
Pavel Pavlov -
pavlov.pavel＠gmail.com
-
Peter Turcan -
Rainer Deyke