7 ms·

The key point, IMO is the fact that C++ compilers are essentially a black box, and you cannot guarantee the code that will be output. When you write C code, you

The key point, IMO is the fact that C++ compilers are essentially a black box, and you cannot guarantee the code that will be output. When you write C code, you pretty much know exactly what the assembly, and thus machine, code will look like (obviously this will vary based upon the compiler optimizations used). This is not true of C++, which is why it is not the most suitable language to write kernel code in. Kernel software is so critical that it is not wise to cede control to a baroque compiler. Especially when C can do everything C++ can (trivia fact: the original C++ compiler was simply a preprocessor that converted the code into C).

grav1tas 16y ago
I think to call C++ compilers a black box and then turn around and say something like gcc is not is a bit of a stretch, and simply unfair to C++. The largess of the GNU C compiler is the very definition of a black box. If you're going to run off and do loads of systems programming, you're going to have to understand exactly how your black box works. This is still very possible with C++, it's just a lot more complicated given the semantics of the language. I think this back and forth sort of breaks down because people say things like C and C++ and it's not clear if they're talking about 1) The languages themselves. 2) The compilers 3) Possible runtimes and other overhead that need to be considered in a stereotypical environment (that is, probably not kernel coding). It tweeks me every time we get into a language war, because a lot of the time the language itself isn't the real point of discussion, but rather it's some sideways way of referring to the toolchain that's popular at the given moment. C++ as a language could very well be tooled to write a kernel, given a good compiler and a semantics that coders stick to (just like C). I feel like the C++/HLL camps are crying for something other than C because they're not interested in the super low level details, but still would like to eek some functionality out of the kernel. They're basically saying, "we would prefer tools other than C" (regardless of whether C++ is a worthwhile and better option, I am unconvinced). I think an even more interesting conversation to have would be: have operating systems kernels become TOO COMPLEX to code in (just) C/ASM? Are we in over our heads? Should we invest in the creation of better tools to handle such large, complex systems or is everything just fine? DISCLAIMER: I actually don't like programming in C++. I will put up with C, but I usually find myself writing in Ruby or Haskell.
- yuhong 16y ago
  Yep, Linus sometimes complains about gcc too.
- DaveMebs 16y ago
  Your point is valid and well taken, but I would like to call out that 1) I specifically mention the use of optimizations as impacting my argument, and 2) I did not mention gcc. I completely agree that for system programming you "have to understand exactly how your black box works," however, I would argue that even if this is technically possible in C++, the cost is prohibitively high. The mapping between C code and machine code is fairly straightforward, /unless obfuscated by compilers and runtimes/. I fundamentally disagree with the notion that you can write /good/ kernel code in a HLL. A kernel is ALL ABOUT interacting with the hardware and performing low level system management. Sure, you could write kernel code in a HLL, but it is just not going to be as performant as if you wrote the code with "the super low level details" in mind. These are important considerations that compilers do not have insight into. I would go on to argue that to anyone who understood the low level details required to write quality kernel code, those details are not something they wish to overlook. Anyone who doesn't understand those details shouldn't be writing kernel code.
phaedrus 16y ago
Calling the output of a C++ compiler a black box and saying it's not a good idea to use C++ for that reason, and implying that C is better because you mostly know what the assembly output will be, boils down to an argument against abstraction. There is a limit to what a hacker can keep in his head at once. You may believe your limit is high, but it does exist. If you eschew abstraction, there is a class of programs you cannot write because you can't keep the complexity managed. This is why it irks me when I see arguments against abstraction - they are short sighted. Now, there are some perfectly good concrete examples of things C++ compilers do which may not be a good idea in kernel code. For instance, C++ exceptions can cause trouble when the stack alternates between C++ and C frames.
- lobster_johnson 16y ago
  Well, the whole point is that C contains so few abstraction in the first place that most dedicated developers can have a mental model of the mapping between language and machine. There are very few abstractions that don't correlate exactly to machine language in some known way. C is all about subroutines (functions), jumps (function calls), pointers and quantities that map directly to registers (int, long) — for the most part a fairly thin veneer on top of modern CISC/RISC machine code. For those abstractions (such as the call stack) that are essentially black boxes, there is the C ABI, which explicitly defines much of the underlying structure.

grav1tas 16y ago

I think to call C++ compilers a black box and then turn around and say something like gcc is not is a bit of a stretch, and simply unfair to C++. The largess of the GNU C compiler is the very definition of a black box. If you're going to run off and do loads of systems programming, you're going to have to understand exactly how your black box works. This is still very possible with C++, it's just a lot more complicated given the semantics of the language. I think this back and forth sort of breaks down because people say things like C and C++ and it's not clear if they're talking about 1) The languages themselves. 2) The compilers 3) Possible runtimes and other overhead that need to be considered in a stereotypical environment (that is, probably not kernel coding). It tweeks me every time we get into a language war, because a lot of the time the language itself isn't the real point of discussion, but rather it's some sideways way of referring to the toolchain that's popular at the given moment. C++ as a language could very well be tooled to write a kernel, given a good compiler and a semantics that coders stick to (just like C). I feel like the C++/HLL camps are crying for something other than C because they're not interested in the super low level details, but still would like to eek some functionality out of the kernel. They're basically saying, "we would prefer tools other than C" (regardless of whether C++ is a worthwhile and better option, I am unconvinced). I think an even more interesting conversation to have would be: have operating systems kernels become TOO COMPLEX to code in (just) C/ASM? Are we in over our heads? Should we invest in the creation of better tools to handle such large, complex systems or is everything just fine? DISCLAIMER: I actually don't like programming in C++. I will put up with C, but I usually find myself writing in Ruby or Haskell.

yuhong 16y ago
Yep, Linus sometimes complains about gcc too.
DaveMebs 16y ago
Your point is valid and well taken, but I would like to call out that 1) I specifically mention the use of optimizations as impacting my argument, and 2) I did not mention gcc. I completely agree that for system programming you "have to understand exactly how your black box works," however, I would argue that even if this is technically possible in C++, the cost is prohibitively high. The mapping between C code and machine code is fairly straightforward, /unless obfuscated by compilers and runtimes/. I fundamentally disagree with the notion that you can write /good/ kernel code in a HLL. A kernel is ALL ABOUT interacting with the hardware and performing low level system management. Sure, you could write kernel code in a HLL, but it is just not going to be as performant as if you wrote the code with "the super low level details" in mind. These are important considerations that compilers do not have insight into. I would go on to argue that to anyone who understood the low level details required to write quality kernel code, those details are not something they wish to overlook. Anyone who doesn't understand those details shouldn't be writing kernel code.

phaedrus 16y ago

Calling the output of a C++ compiler a black box and saying it's not a good idea to use C++ for that reason, and implying that C is better because you mostly know what the assembly output will be, boils down to an argument against abstraction. There is a limit to what a hacker can keep in his head at once. You may believe your limit is high, but it does exist. If you eschew abstraction, there is a class of programs you cannot write because you can't keep the complexity managed. This is why it irks me when I see arguments against abstraction - they are short sighted. Now, there are some perfectly good concrete examples of things C++ compilers do which may not be a good idea in kernel code. For instance, C++ exceptions can cause trouble when the stack alternates between C++ and C frames.

lobster_johnson 16y ago
Well, the whole point is that C contains so few abstraction in the first place that most dedicated developers can have a mental model of the mapping between language and machine. There are very few abstractions that don't correlate exactly to machine language in some known way. C is all about subroutines (functions), jumps (function calls), pointers and quantities that map directly to registers (int, long) — for the most part a fairly thin veneer on top of modern CISC/RISC machine code. For those abstractions (such as the call stack) that are essentially black boxes, there is the C ABI, which explicitly defines much of the underlying structure.