complaining about C and not seeing its advantages. Yes, it has advantages, or rather one. Or more precisely, its compiler has this advantage. It is the ability to generate machine code, which is quite efficient in operation.
But also this is not just the Compiler but also because c is designed to allow for easy optimization on a language level.
But note that the foundations were laid at the very beginning of the 1970s. C has been adapted to hardware, but what hardware? Also this one from the 70's. Gradually, changes were introduced in C (compilers). In the first years, this was acceptable because there was not so much of this code yet. During these first 20 years, there were quite significant changes in the CPU architecture, in C compilers, and therefore in the C language specification. After that time, changes in the C compiler could not have been too big, because at that time there was a lot of code in the C language. After another 10 years (around 2000), the C foundations related to processor architecture certainly "diverged". Hence the considerable complexity of C compilers, because it was no longer possible to "translate" C code into CPU instructions as easily as in the 70s. I wonder how many differences between CPU architectures and the C specification are "patched" using a preprocessor today? This is certainly the case with microcontrollers. In the case of computers, it can probably be noticed as well. Just look at the Linux kernel code, for example.
To give a positive and a negative example, first the positive, the probably most important information for the Compiler to do optimizations is the information what data is constant and what isn't. The C type system does allow to Tag any object as const, so you can have pointers to const data, records can contain some mutable and some immutable fields, etc. Many languages do not have that. Pascal only has const for parameters and this only on the top level, meaning you cannot express something like a mutable pointer to const data like you can in C. So many optimizations the C Compiler does are things the FPC could never do because the Pascal language does not give the developer the tools to express this information in code.
And probably some of these solutions could also be useful in Pascal. Maybe not necessarily implemented in the same way as in C, but to give the same results. Because if it could be implemented in a C compiler, why shouldn't it be possible to implement it in a compiler of another language? A separate issue is whether compiler programmers would agree to add to FPC those C features that could be useful for hardware support. And this doesn't have to apply to creating an OS, but for example to programming microcontrollers. And I don't mean solutions like C-style assignment operators, because that's a terrible solution.
And for a negative example, the design of classes in object Pascal is inherently inefficient. Creation and destruction of a class instance requires multiple virtual function calls, the creation of implicit exception handlers, etc. The design of classes in Pascal means they cannot be as efficient as e.g. C structs (note that die to RTTI also Pascal records can be much more inefficient) or C++ classes
Comparing implementations of C structures and Object Pascal classes is probably not a good example. But comparing implementations of C++ and Object Pascal classes – I agree. But, again, if something could be done in one compiler of one language (with similar goals and features), why couldn't it be done in another? Again, the issue of compiler programmers comes back
Again you cannot decouple the language design from the capabilities of the Compiler. And again a lot of the decisions that people usually criticize about C stem from that. E.g. is char signed or u signed? Well it's undefined because of optimizations. Is int/short/long 16, 32, 64 or whatever bit? Undefined because of optimizations.
Yes, I agree that you can't really separate the design of a language from its compiler. But in the case of C and those types mentioned, you get the impression that the desire for optimization is much more important than the use of that compiler (i.e.: the language specification). Because the price you have to pay for it is the uncertainty of how the code will work on different processors. And to alleviate this problem, a prosthesis in the form of a preprocessor is probably used. Otherwise, the code will be non-portable between different CPU architectures.
Like most of the "problems" of the design of C either boil down to features required for developing low level systems like OS, drivers, etc. or Optimizations.
There are a lot of things in C that make it awful to use as a high level language, but that's because C was never intended to fill that role. The position C is in is not despite it's design, but because of it. And you don't need to like it for a lot of use cases, like I wouldn't want to write a GUI data management software in C, this doesn't mean it's badly designed, it's just not designed for that usecase
Yes, you're right. And that's why C is unlikely to be "improved". What is more likely is that the FPC will be supplemented with some features necessary to support the hardware (which I would love to use).
Recent
