3 ms·

No, I'm saying that there could be anything from a one word change to the standard that doesn't affect compilers at all to safety by default with a clang tidy p

No, I'm saying that there could be anything from a one word change to the standard that doesn't affect compilers at all to safety by default with a clang tidy performance warning. Clang tidy and the core guidelines have already broken the textbook Hello, World! with performance-avoid-endl warning, so I don't see why the common textbook way to write things should be our guiding principle here. Of course, the common textbook way to write things would continue working regardless, it'd just have a negligible performance cost.

pcwalton 2y ago
Have you measured the performance cost? I highly suspect it is not negligible, given that it's the most common way to write inner loops, which are the most performance-sensitive type of code.
- AlotOfReading 2y ago
  There's a range of possible performance costs. Let's talk about the lowest: the standard changes "the behavior is undefined" to "the behavior is unspecified". Everything else is the same, except that suddenly your program still has semantic meaning if there's signed overflow. Why would that be problematic?
  - pcwalton 2y ago
    What does "unspecified" mean in this context? If you mean "the value of a signed integer is unspecified if it overflows", then I can still construct cases in which you lose the optimization that widens a loop induction variable from 32-bit to 64-bit. For example, take this code: for (int i = 0; i != n; i++) sum += a[i]; If n is -2, will this function include the element at a[(uint64_t)INT_MAX + 1] in the sum? If signed overflow is UB, then the answer is "maybe", and thus i and n can legally be promoted to 64-bit. If signed overflow is unspecified, but the result must still fit in a 32-bit integer, then the answer is "no", and i and n can't legally be promoted.
    - AlotOfReading 2y ago
      "unspecified" in the standards sense of "unspecified behavior", i.e. any chosen behavior is permissible. The compiler doesn't have to document the behavior and the behavior isn't constrained, it just isn't undefined. That's still better than where we are today.
      - steveklabnik 2y ago
        I looked this up after you mentioned it upthread, I thought you meant implementation-defined, but I learned that yeah, this exists too. The difference is that implementation-defined requires documentation of the choice made, whereas unspecified does not. However, > the behavior isn't constrained C++23, at least, does say > The range of possible behaviors is usually delineated by this document. So there are sometimes some constraints.

pcwalton 2y ago

Have you measured the performance cost? I highly suspect it is not negligible, given that it's the most common way to write inner loops, which are the most performance-sensitive type of code.

AlotOfReading 2y ago
There's a range of possible performance costs. Let's talk about the lowest: the standard changes "the behavior is undefined" to "the behavior is unspecified". Everything else is the same, except that suddenly your program still has semantic meaning if there's signed overflow. Why would that be problematic?
- pcwalton 2y ago
  What does "unspecified" mean in this context? If you mean "the value of a signed integer is unspecified if it overflows", then I can still construct cases in which you lose the optimization that widens a loop induction variable from 32-bit to 64-bit. For example, take this code: for (int i = 0; i != n; i++) sum += a[i]; If n is -2, will this function include the element at a[(uint64_t)INT_MAX + 1] in the sum? If signed overflow is UB, then the answer is "maybe", and thus i and n can legally be promoted to 64-bit. If signed overflow is unspecified, but the result must still fit in a 32-bit integer, then the answer is "no", and i and n can't legally be promoted.
  - AlotOfReading 2y ago
    "unspecified" in the standards sense of "unspecified behavior", i.e. any chosen behavior is permissible. The compiler doesn't have to document the behavior and the behavior isn't constrained, it just isn't undefined. That's still better than where we are today.
    - steveklabnik 2y ago
      I looked this up after you mentioned it upthread, I thought you meant implementation-defined, but I learned that yeah, this exists too. The difference is that implementation-defined requires documentation of the choice made, whereas unspecified does not. However, > the behavior isn't constrained C++23, at least, does say > The range of possible behaviors is usually delineated by this document. So there are sometimes some constraints.