Re: Seeking Endorsement: Boost.int128
Andrey Semashev via Boost <[email protected]>
| Newsgroups | gmane.comp.lib.boost.devel |
|---|---|
| Message-ID | <[email protected]> |
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_deviation >> >> 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.html 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? _______________________________________________ Boost mailing list -- [email protected] To unsubscribe send an email to [email protected] https://lists.boost.org/mailman3/lists/boost.lists.boost.org/ Archived at: https://lists.boost.org/archives/list/[email protected]/message/MKZWAGTCG6ACU63VKSQTCQJ4SQVXMBQL/