4 ms·

What's the alternative? Change the semantics of the comparison operator so that code looks cleaner? That means that when you read a comparison in source you hav

by rictic 4y ago

What's the alternative? Change the semantics of the comparison operator so that code looks cleaner? That means that when you read a comparison in source you have to know how it's going to be compiled in order to tell if the code is correct or not.

lifthrasiir 4y ago
You can opt in a new behavior, attribute syntax added in C++11 should make this much more bearable. In fact, I'm honestly surprised that this mode of language evolution didn't seem to be frequently discussed in C++ WG at all; ECMAScript had `use strict` which is very much the same thing and well received, and if ECMAScript can do it with a lot of legacy code, there is no real reason C++ can do the same.
- sharikous 4y ago
  I don't know why they don't do that either. Perhaps because a transition like that will take multiple decades of consistent and steady guidance to succeed, given the nature and size of C++ codebases and nobody will take the responsibility for it?
- 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 ago
    I 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 ago
      Converting a signed negative number to unsigned is UB.
      - anonymoushn 4y ago
        Can 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
bruce343434 4y ago
Welcome to every language that has the balls to say "yeah you know what, that didn't work, here's a revision". Stuff is deprecated all the time.

by rictic 4y ago

lifthrasiir 4y ago

You can opt in a new behavior, attribute syntax added in C++11 should make this much more bearable. In fact, I'm honestly surprised that this mode of language evolution didn't seem to be frequently discussed in C++ WG at all; ECMAScript had `use strict` which is very much the same thing and well received, and if ECMAScript can do it with a lot of legacy code, there is no real reason C++ can do the same.

sharikous 4y ago
I don't know why they don't do that either. Perhaps because a transition like that will take multiple decades of consistent and steady guidance to succeed, given the nature and size of C++ codebases and nobody will take the responsibility for it?
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 ago
  I 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 ago
    Converting a signed negative number to unsigned is UB.
    - anonymoushn 4y ago
      Can 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

bruce343434 4y ago

Welcome to every language that has the balls to say "yeah you know what, that didn't work, here's a revision". Stuff is deprecated all the time.