3 ms·

There's an old adage that a computer only does what you tell it to do. What I love about C? It really does only do what you ask it to; nothing more, nothing les

There's an old adage that a computer only does what you tell it to do. What I love about C? It really does only do what you ask it to; nothing more, nothing less.

JohannL 14y ago
I was just typing up a reply saying just that in more words when I saw yours; so for the sake of efficiency I'll just make my post a pointer to yours ^^
derleth 14y ago
> It really does only do what you ask it to; nothing more, nothing less. Not even assembly language has this property anymore, especially in the presence of an OS. Which leads me to what I think is C's greatest weakness: It's no longer a thin layer over assembly language. It is so far removed from the current trends hardware design it doesn't even have functions that implement memory barriers as part of the core language, let alone any language features to help you take advantage of whatever SIMD hardware the machine possesses. Part of this is C becoming a victim of its own success: People expect the same language to compile down to ARM and x86-64 and IBM mainframe (zSeries) and so on and so forth machine code, and do it in an efficient manner. Since low-end ARM chips don't have SIMD, C can't have SIMD, the thinking goes (even though low-end hardware doesn't have FP opcodes, either, but floating-point math is still part of the C standard). They rely on compilers to make it fast, which is reasonable to some extent but it's also the same thing you rely on when you write in Haskell. It's contrary to the spirit of things. I'm not advocating a return to assembly language. That would be massively stupid. However, it would be nice to have a language with concise syntax that also allows you access to the processor's status word (the carry flag, for instance).
- kzrdude 14y ago
  C has memory barriers now in C11.
- gaius 14y ago
  Right, but you would just link against the appropriate library, BLAS or whatever, that is hand-tuned for your platform and exposes a C API.
  - lmm 14y ago
    For the kind of problem where I can take that approach, I also have a python API onto BLAS, and guess which I prefer to write my programs in.
    - gaius 14y ago
      There's nothing in the "Python way" that precludes dropping into C as and when it makes sense to do so. A C programmer is able to make that decision independently.
anonymoushn 14y ago
When C does what you ask it to do, you're probably just getting lucky. It's more or less impossible to write a nontrivial C program without relying on undefined behavior.
- qznc 14y ago
  Enable all warnings and fix them!
- stephencanon 14y ago
  With the exception of the translation limits (a strict reading of which may allow a compiler that can only compile a single program), it's pretty much trivial to avoid undefined behavior. Implementation-defined behavior can be harder to avoid, but that's not a problem if you're targeting a known implementation.

There's an old adage that a computer only does what you tell it to do. What I love about C? It really does only do what you ask it to; nothing more, nothing less.

JohannL 14y ago

I was just typing up a reply saying just that in more words when I saw yours; so for the sake of efficiency I'll just make my post a pointer to yours ^^

derleth 14y ago

> It really does only do what you ask it to; nothing more, nothing less. Not even assembly language has this property anymore, especially in the presence of an OS. Which leads me to what I think is C's greatest weakness: It's no longer a thin layer over assembly language. It is so far removed from the current trends hardware design it doesn't even have functions that implement memory barriers as part of the core language, let alone any language features to help you take advantage of whatever SIMD hardware the machine possesses. Part of this is C becoming a victim of its own success: People expect the same language to compile down to ARM and x86-64 and IBM mainframe (zSeries) and so on and so forth machine code, and do it in an efficient manner. Since low-end ARM chips don't have SIMD, C can't have SIMD, the thinking goes (even though low-end hardware doesn't have FP opcodes, either, but floating-point math is still part of the C standard). They rely on compilers to make it fast, which is reasonable to some extent but it's also the same thing you rely on when you write in Haskell. It's contrary to the spirit of things. I'm not advocating a return to assembly language. That would be massively stupid. However, it would be nice to have a language with concise syntax that also allows you access to the processor's status word (the carry flag, for instance).

kzrdude 14y ago
C has memory barriers now in C11.
gaius 14y ago
Right, but you would just link against the appropriate library, BLAS or whatever, that is hand-tuned for your platform and exposes a C API.
- lmm 14y ago
  For the kind of problem where I can take that approach, I also have a python API onto BLAS, and guess which I prefer to write my programs in.
  - gaius 14y ago
    There's nothing in the "Python way" that precludes dropping into C as and when it makes sense to do so. A C programmer is able to make that decision independently.

anonymoushn 14y ago

When C does what you ask it to do, you're probably just getting lucky. It's more or less impossible to write a nontrivial C program without relying on undefined behavior.

qznc 14y ago
Enable all warnings and fix them!
stephencanon 14y ago
With the exception of the translation limits (a strict reading of which may allow a compiler that can only compile a single program), it's pretty much trivial to avoid undefined behavior. Implementation-defined behavior can be harder to avoid, but that's not a problem if you're targeting a known implementation.