On 29 Apr 2026 01:51, Matt Borland wrote:
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.
It is the same behavior as the built-in types have when you set -Werror -Wsign-conversion -Wconversion which I think is uncontroversial to say is best practice.
Personally, I never use -Werror and don't consider this a good practice.
If this is behavior is removed from the library, then when a user does set the aforementioned flags they will not apply to mixed library type - builtin type operations which I think is the bigger risk. All of the analysis is static; there is zero runtime overhead introduced by these checks.
You could try emitting a warning manually, if you want. There's this example, although I don't know how well it works: https://www.boost.org/doc/libs/1_91_0/libs/serialization/doc/static_warning.... Then you would provide user with a macro to disable the warning. This would be better than disabling the operators by default. However, my complaint was not about warnings but about the behavior when the operators are enabled by defining the BOOST_INT128_ALLOW_SIGN_COMPARE/BOOST_INT128_ALLOW_SIGN_CONVERSION macro. When the comparison operators are enabled, their behavior differs from the built-in ones, and I think this is a problem.
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?
For an operation between a builtin and a int128 type of opposite sign, the builtin will be cast to the int128 type. These sign conversions match the behavior of __(u)int128_t. I will edit these sections to make them more clear.
Thanks, but do note that for an operation taking int128_t and uint128_t (in any order), int128_t is always expected to be converted to uint128_t. Is this expectation correct?