4 ms·
This isn't that, though. C/C++ continue to leave undefined behavior in specifically for performance. It would, AFAICT, be standard-compliant behavior for a comp
by titzer 4y ago
This isn't that, though. C/C++ continue to leave undefined behavior in specifically for performance. It would, AFAICT, be standard-compliant behavior for a compiler to handled mixed-sign comparisons involving negative numbers in the intuitive number-line way, but the language specification doesn't require this because it means another comparison[1]. Because performance, it's the programmer's responsibility to avoid having negative numbers in such comparisons. And woe to they who have bugs in their programs, the compiler may even exploit that UB to assume the code is never reached. The default is all wrong because the priorities are all wrong.
[1] It's non-obvious to me why an implicit conversion with potential UB would ever be a good idea. If a programmer really did want a UB-having single-machine compare between a signed (but non-negative) int and an unsigned int, they could write an explicit static_cast and then compare. Such a static_cast would be the UB-having nop that unlocked a non-UB comparison. You'd get the exact machine code that you wanted, but you had to opt into UB. Bad default that the short, intuitive-looking code has UB.
- anonymoushn 4y agoI don't think this is correct. Comparison operators are defined to perform the usual arithmetic conversions before they are applied, and the usual arithmetic conversions for converting to unsigned integer types are defined like so: > If the destination type is unsigned, the resulting value is the least unsigned integer congruent to the source integer (modulo 2n where n is the number of bits used to represent the unsigned type). [Note: In a two’s complement representation, this conversion is conceptual and there is no change in the bit pattern (if there is no truncation). ]
- titzer 4y agoConverting a signed negative number to unsigned is UB.
- anonymoushn 4y agoCan you provide a citation? I have above quoted the part of the standard that defines the value of the result of the conversion. It looks like C++20 updated this so that conversion both ways is defined in a way that preserves two's complement bit-patterns, which you can see here: https://eel.is/c++draft/conv#integral-3 https://eel.is/c++draft/conv#integral-3