Am 29.04.26 um 00:51 schrieb Matt Borland via Boost:
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. 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. I'm a bit confused about the relation of "behavior" to warning flags. My understanding of that would be that the library shows a compile-time error as it would with that warning flag(s) and Werror enabled. Is that the case?
The docs however say:
With |uint128_t| we have checks even in this case like so: ... if(rhs >= 0) ... else return true;
This contradicts (my understanding of) the stated behavior to fail compilation on mixed comparison and also the "zero runtime overhead". So what is it? While I see how this behavior is less surprising for beginners, advanced users might rely on the wrap-around (mod 2^N) behavior. Semi-contrived example: `operator[](signed_t idx) { if(size() > idx) return elements[idx]; }` So I'd rather have this not compile (e.g. via static_assert) to be similar to the Werror case, than silently deviate from "standard behavior". - Alex