On 28 Apr 2026 20:02, Matt Borland via Boost wrote:
Dear All,
I am seeking endorsement for review of my library int128 [1]. The library requires only C++14, is header only, and has no mandatory dependencies. What does int128 provide? Two portable and performant types: a 128-bit signed integer and a 128-bit unsigned integer, as well as a standard library for them. The performance of these types have been tuned and tested on a variety of architectures to include: x64, x32, s390x, ARM64, ARM32, PPC64LE. Both of the types and most of their library functions also work inside CUDA kernels. Benchmarks against Boost.Multiprecision, Absl, MSVC's software 128-bit integers, and built-ins, are available [2].
I would find this library useful. I have doubts regarding the signed/unsigned comparison behavior deviation described here: https://develop.int128.cpp.al/uint128_t.html#uint128_t_sign_compare_behavior... While I understand the reasons for wanting to implement comparison this way, I thing I would rather prefer to keep the behavior consistent with the rest of integer types. That is, make it the same as for built-in integer types. Yes, I understand this may produce surprising results to some, but IMHO, consistency is more important, as it eliminates a special case in the user's mental model. And the result is no longer surprising once you learn how comparisons work in C++, which you must learn anyway for built-in integer types. Also, I don't quite understand what you are saying in these two sections: https://develop.int128.cpp.al/uint128_t.html#u128_operator_behavior https://develop.int128.cpp.al/int128_t.html#i128_operator_behavior In one place you're saying you convert signed to unsigned to perform the operation, in the other - the other way around. Which way is it? I would expect the operators to work the same way regardless of the order of signed/unsigned arguments, and to follow the rules for the built-in integer types (i.e. to convert signed to unsigned).