3 ms·

I'm pretty sure that's replying directly to the comment about how c is close to assembly and that if you add that line of code somewhere you know there's a vari

I'm pretty sure that's replying directly to the comment about how c is close to assembly and that if you add that line of code somewhere you know there's a variable getting incremented. Doesn't really matter whether or not it's useful, the point is that the behavior isn't exactly what you wrote

jmillikin 2y ago
To reiterate, claiming that C can be described as "portable assembly" is not a claim that it is literally a package of assembler macros that emit deterministic machine code for each individual source expression. I linked these in another comment, but here's some examples of straightforward-looking integer addition emitting more complex compiler output for other languages that compile to native code: Haskell: https://godbolt.org/z/vdeMKMETT https://godbolt.org/z/vdeMKMETT C++: https://godbolt.org/z/dedcof9x5 https://godbolt.org/z/dedcof9x5
- eru 2y ago
  The Haskell version deals with both laziness and also detects overflow. Your C++ example has a lot more code than the C example, I'm not sure why you'd expect it to produce the same output?
johnisgood 2y ago
https://godbolt.org/z/r39jK1ddv https://godbolt.org/z/r39jK1ddv It increments, then decrements with -O0 though. I do not see the issue still, as the behavior is expected with -O0; increments then decrements.
- eru 2y ago
  There's nothing in the C standard that enforces the observed -O0 behaviour. Your compiler might change tomorrow.
  - johnisgood 2y ago
    How likely is that to happen, and in which languages can you either optimize or not AND where the compiler might not change tomorrow though? David Hume said that we cannot know if the sun is going to rise tomorrow just because it has always did before. See "problem of induction", https://philosophynow.org/issues/160/Humes_Problem_of_Induction https://philosophynow.org/issues/160/Humes_Problem_of_Induct....
    - eru 2y ago
      The C standard guarantees certain behaviours that will not change, even if your C compiler changes. That's the whole point of the standard. And it has nothing to do with the problem of induction. But the standard does not guarantee that specific assembly instructions will be used.
      - johnisgood 2y ago
        Sure, but what programming language or its standard guarantees it (and its compilers in practice, of course), then? You said "Your compiler might change tomorrow.", but does it not apply to EVERY programming language's compiler?
        eru 2y ago
        > You said "Your compiler might change tomorrow.", but does it not apply to EVERY programming language's compiler? Yes. I wasn't the one trying to argue that C is special in this regard. Just the opposite.

jmillikin 2y ago

To reiterate, claiming that C can be described as "portable assembly" is not a claim that it is literally a package of assembler macros that emit deterministic machine code for each individual source expression. I linked these in another comment, but here's some examples of straightforward-looking integer addition emitting more complex compiler output for other languages that compile to native code: Haskell: https://godbolt.org/z/vdeMKMETT https://godbolt.org/z/vdeMKMETT C++: https://godbolt.org/z/dedcof9x5 https://godbolt.org/z/dedcof9x5

eru 2y ago
The Haskell version deals with both laziness and also detects overflow. Your C++ example has a lot more code than the C example, I'm not sure why you'd expect it to produce the same output?

johnisgood 2y ago

https://godbolt.org/z/r39jK1ddv https://godbolt.org/z/r39jK1ddv It increments, then decrements with -O0 though. I do not see the issue still, as the behavior is expected with -O0; increments then decrements.

eru 2y ago
There's nothing in the C standard that enforces the observed -O0 behaviour. Your compiler might change tomorrow.
- johnisgood 2y ago
  How likely is that to happen, and in which languages can you either optimize or not AND where the compiler might not change tomorrow though? David Hume said that we cannot know if the sun is going to rise tomorrow just because it has always did before. See "problem of induction", https://philosophynow.org/issues/160/Humes_Problem_of_Induction https://philosophynow.org/issues/160/Humes_Problem_of_Induct....
  - eru 2y ago
    The C standard guarantees certain behaviours that will not change, even if your C compiler changes. That's the whole point of the standard. And it has nothing to do with the problem of induction. But the standard does not guarantee that specific assembly instructions will be used.
    - johnisgood 2y ago
      Sure, but what programming language or its standard guarantees it (and its compilers in practice, of course), then? You said "Your compiler might change tomorrow.", but does it not apply to EVERY programming language's compiler?
      - eru 2y ago
        > You said "Your compiler might change tomorrow.", but does it not apply to EVERY programming language's compiler? Yes. I wasn't the one trying to argue that C is special in this regard. Just the opposite.