Re: Seeking Endorsement: Boost.int128
Matt Borland via Boost <[email protected]>
| Newsgroups | gmane.comp.lib.boost.devel |
|---|---|
| Message-ID | <mdqaH3LpeaQusD3EH2KPfE_KKwpDL7JNqFcCD2ztiyJNCNQV_PRPKIh9lQIt-sOrlfikfObrCbTVvvIxAHP6Sssu8F43Qo9sCf1TpW9Vbtc=@mattborland.com> |
> 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. 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. > 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. Matt _______________________________________________ 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/TNHTJ72722KDNKHOHL52WVFNXGOFSHQA/
publickey - [email protected] - 0xC1382EAD.asc
(application/pgp-keys, 653 B)
-----BEGIN PGP PUBLIC KEY BLOCK----- xjMEX2wgdBYJKwYBBAHaRw8BAQdAUHOh0KpbZCszhdvKztWj4C6FR1ozMBQE waBi3m2PJHLNK21hdHRAbWF0dGJvcmxhbmQuY29tIDxtYXR0QG1hdHRib3Js YW5kLmNvbT7CjwQQFgoAIAUCX2wgdAYLCQcIAwIEFQgKAgQWAgEAAhkBAhsD Ah4BACEJEFmBWlVCFaWlFiEEwTgurTcoHwbdSbIsWYFaVUIVpaVWuwEA77rm OA4TB6Xxe6q8gI42bEICMhMyZKSMcakz39/djYkBAMJOG+IGQC/d0n3dsl10 Kg/oxX88kFO1oPKn4/XW+ToBzjgEX2wgdBIKKwYBBAGXVQEFAQEHQOsmo6wR UuXRAvFIiqmQkzYrPyvKYKna2z4ZtmnTQMkMAwEIB8J4BBgWCAAJBQJfbCB0 AhsMACEJEFmBWlVCFaWlFiEEwTgurTcoHwbdSbIsWYFaVUIVpaWUJwEA5G0c ZRnG5WGNErI+y90iQrTv02i4Ivhv7twoFcLD/zwA/jKypw+vehE99mEj1/uI EkoDFlNzQZqNldbjRcPyI5UH =462S -----END PGP PUBLIC KEY BLOCK-----
signature.asc
(application/pgp-signature, 343 B)
-----BEGIN PGP SIGNATURE----- Version: ProtonMail wrsEARYKAG0FgmnxOeAJEFmBWlVCFaWlRRQAAAAAABwAIHNhbHRAbm90YXRp b25zLm9wZW5wZ3Bqcy5vcmdjEKiqO+MEpKSt3GvL8PEVePQwgbusVcn6GyCa 7bXIJRYhBME4Lq03KB8G3UmyLFmBWlVCFaWlAAAjxQEA6jW8SctwnpRf6LJt C7nhzxXQaIZFjd6SOBv3uKlOoo0A/3pmbrfcsFf8Cv5ycdvVT0TvYm8QcWBg jGTVHlfcQ34O =UUQz -----END PGP SIGNATURE-----