4 ms·

> the transparency and predictability of what machine code gets generated from the source code. This gets said a lot, but unless you're writing C code for a mi

> the transparency and predictability of what machine code gets generated from the source code. This gets said a lot, but unless you're writing C code for a microcontroller (or a PDP11), that isn't even close to being true. > When you write "a + b", you won't end up with kilobytes of machine code just because someone in some header overloaded the + operator. You can't overload "+" for integers or floats. If you add two numbers together, you get what you expect, always. If they're not numbers, and somehow you expected `a + b` to work without an overloaded operator, then I don't know what to say. > You want a function, you define that function. Then you define it again for another type, then again, then again... Then you write a macro and now your colleagues hate you. > All of these constructs, should they be added to the language, will result in a compiler generating heaps of code from a simple code snippet Not necessarily.

huhtenberg 7y ago
> This gets said a lot, No, this actually doesn't get said a lot, however the simplicity of C compilation semantics is one of its biggest strengths. > ... but unless you're writing C code for a microcontroller (or a PDP11), that isn't even close to being true. Do humor us with an example of a C code that compiles into something that is "not even close" to what you'd reasonably expect.
- umanwizard 7y ago
  For example: https://godbolt.org/z/m3xSse https://godbolt.org/z/m3xSse
  - huhtenberg 7y ago
    How is basic loop unrolling is "not even close" to the expected result when you explicitly ask for optimization with O3?
    - umanwizard 7y ago
      This isn’t basic loop unrolling; it’s replacing an entire loop with a closed form mathematical formula.
      - huhtenberg 7y ago
        It's a form of loop unrolling. Regardless of the term, this is still very much in the ballpark of what you'd expect when asking for optimization.
phkahler 7y ago
>> You can't overload "+" for integers or floats. If you add two numbers together, you get what you expect, always. If they're not numbers, and somehow you expected `a + b` to work without an overloaded operator, then I don't know what to say. You can't overload the + operator in C. If you see a+b in code you know it is adding two numbers (or a compile error). In C++ it could be doing anything. In C you may question the size or type (fp vs int) of the variables, but not the operator. + does addition. Always.

huhtenberg 7y ago

> This gets said a lot, No, this actually doesn't get said a lot, however the simplicity of C compilation semantics is one of its biggest strengths. > ... but unless you're writing C code for a microcontroller (or a PDP11), that isn't even close to being true. Do humor us with an example of a C code that compiles into something that is "not even close" to what you'd reasonably expect.

umanwizard 7y ago
For example: https://godbolt.org/z/m3xSse https://godbolt.org/z/m3xSse
- huhtenberg 7y ago
  How is basic loop unrolling is "not even close" to the expected result when you explicitly ask for optimization with O3?
  - umanwizard 7y ago
    This isn’t basic loop unrolling; it’s replacing an entire loop with a closed form mathematical formula.
    - huhtenberg 7y ago
      It's a form of loop unrolling. Regardless of the term, this is still very much in the ballpark of what you'd expect when asking for optimization.

phkahler 7y ago

>> You can't overload "+" for integers or floats. If you add two numbers together, you get what you expect, always. If they're not numbers, and somehow you expected `a + b` to work without an overloaded operator, then I don't know what to say. You can't overload the + operator in C. If you see a+b in code you know it is adding two numbers (or a compile error). In C++ it could be doing anything. In C you may question the size or type (fp vs int) of the variables, but not the operator. + does addition. Always.