3 ms·

The problem is not as much C, but coding practices that make it seem like we're still in the 1970s. Codebases like curl use C at a very low level. But C has fun

The problem is not as much C, but coding practices that make it seem like we're still in the 1970s. Codebases like curl use C at a very low level. But C has functions, has structures, has a lot of functionality to allow you to write at a higher level, instead of chasing pointers at each while statement. Code that handles pointers could be abstracted in the same way people will have to do in other languages.

zxilly 2y ago
What about performance overheads? I think the reason a lot of people write C is that they have direct control over the generated assembly to maximise performance.
- pjc50 2y ago
  > they have direct control over the generated assembly They do not. As seen by all the "optimizer has done weird stuff" bugs.
- aaronmdjones 2y ago
  Even direct control over the generated assembly (C does not provide this; only writing assembler does, and only if you don't do things like LTO) is not sufficient. Modern CPUs do all sorts of weird things. Assembly instructions can be executed out of order. Your conditional jump instruction can be speculatively executed before the condition's truth is known. Fetches from main memory can be reordered. Even more wildly, copying the contents of one register to another is often a no-op. Yes, that's right; the following code: mov edx, eax ... does next to nothing on some modern CPUs. All it does sometimes is set an internal note to the effect of "later references to edx should read/write eax instead", until that note is cleared by some other operation. You can write your assembler with the best of intentions as to how it should behave, only to discover that the CPU does things entirely differently. You still end up getting the same observable result out of it, but any timing and order of operation guarantees went out the window decades ago.
pjmlp 2y ago
Bell Labs 1970s, I advise learning about what already existed elsewhere in systems programming languages.
sgarland 2y ago
Pointers are not a difficult concept.

zxilly 2y ago

What about performance overheads? I think the reason a lot of people write C is that they have direct control over the generated assembly to maximise performance.

pjc50 2y ago
> they have direct control over the generated assembly They do not. As seen by all the "optimizer has done weird stuff" bugs.
aaronmdjones 2y ago
Even direct control over the generated assembly (C does not provide this; only writing assembler does, and only if you don't do things like LTO) is not sufficient. Modern CPUs do all sorts of weird things. Assembly instructions can be executed out of order. Your conditional jump instruction can be speculatively executed before the condition's truth is known. Fetches from main memory can be reordered. Even more wildly, copying the contents of one register to another is often a no-op. Yes, that's right; the following code: mov edx, eax ... does next to nothing on some modern CPUs. All it does sometimes is set an internal note to the effect of "later references to edx should read/write eax instead", until that note is cleared by some other operation. You can write your assembler with the best of intentions as to how it should behave, only to discover that the CPU does things entirely differently. You still end up getting the same observable result out of it, but any timing and order of operation guarantees went out the window decades ago.

pjmlp 2y ago

Bell Labs 1970s, I advise learning about what already existed elsewhere in systems programming languages.

sgarland 2y ago

Pointers are not a difficult concept.