Why is C as programming language still so prominent when it comes to OS programming? Shouldn't C++ have replaced it a long time ago as its successor?
Linus Torvalds hates it. He didn't implement GIT using C++ too, and here's his reason (for GIT implementation): http://thread.gmane.org/gmane.comp.version-control.git/57643/focus=57918
If you perform benchmarks of the two languages, C is generally much faster (because it doesn't have to deal with the overhead of objects). And it's much better suited to certain low-level programming than C++ is.
C was designed from the beginning to be a "sweet spot" between a "high level" language and assembly language. That makes it ideal for use in any real time application, such as an operating system.
The primary reason that Linux isn't written in C++ is of course that Linus Torvalds hates it.
There are also technical reasons why C might be preferred over C++ for things like kernels.
New architectures and platforms will typically have a C compiler long before they have a C++ compiler. C is a much simpler and easier language to implement.
Portability of C code between compilers has been far better. Portability of C++ code was long something that required a lot of discipline to achieve. See the Mozilla portability guide for insight into the lengths that programmers go to to create portable C++.
C++ requires a more complicated runtime to support things like exception handling and RTTI. This can be hard to provide in an unhosted environment. Compilers do permit you to switch them off.
Apparently simple statements can hide expensive operations, thanks to operator-overloading. This would normally be considered a Good Thing, but in an embedded/kernel development world people like to be able to see where expensive operations are being performed.
Here are some non-reasons:
C++ is slower than C. C++ has the same overheads as C. Additional overheads typically only arise when using features C doesn't support.
Virtual dispatch is slow. Virtual dispatch is slower than static dispatch, but the performance penalty is modest, particularly when used judiciously. The Linux kernel already makes wide use of jump tables for performing dynamic dispatch.
Templates cause massive code bloat. This is potentially true. However the Linux kernel uses macros to perform similar code generation effects, for instance creating typed data structures, or for retrieving a containing structure from a pointer to a member.
Encapsulation hurts performance.
Here are some reasons that a kernel in C++ might be a good idea:
Less boiler plate code to use the common dynamic dispatch pattern.
Templates give a safer way to perform simple code generation, with no performance penalty over macros.
The class mechanism encourages programmers to encapsulate their code.
See this kerneltrap thread for actual discussion on C++ in the kernel.
Just a quote: "In fact, in Linux we did try C++ once already, back in 1992. It sucks. Trust me - writing kernel code in C++ is a BLOODY STUPID IDEA."
Here I got one more link that I am pasting here:
http://www.kernel.org/pub/linux/docs/lkml/
Why don't we rewrite the Linux kernel in C++?
- (ADB) Again, this has to do with practical and theoretical reasons. On the practical side, when Linux got started gcc didn't have an efficient C++ implementation, and some people would argue that even today it doesn't. Also there are many more C programmers than C++ programmers around. On theoretical grounds, examples of OS's implemented in Object Oriented languages are rare (Java-OS and Oberon System 3 come to mind), and the advantages of this approach are not quite clear cut (for OS design, that is; for GUI implementation KDE is a good example that C++ beats plain C any day).
- (REW) In the dark old days, in the time that most of you hadn't even heard of the word "Linux", the kernel was once modified to be compiled under g++. That lasted for a few revisions. People complained about the performance drop. It turned out that compiling a piece of C code with g++ would give you worse code. It shouldn't have made a difference, but it did. Been there, done that.
- (REG) Today (Nov-2000), people claim that compiler technology has improved so that g++ is not longer a worse compiler than gcc, and so feel this issue should be revisited. In fact, there are five issues. These are:
@Richard Wolf - mostly agree.
I think the runtime-support issues is the primary obstacle, however. I have tried to implement a on-the-metal kernel in C++, so I can tell you from experience that having to write your own librt isn't much fun (i.e., think the 'new' keyword), and programming C++ while trying to avoid stepping in one of those runtime-supported features takes a lot of power of it as well. Portability wasn't really a big concern - the GCC compiler is pretty portable and as of 3.4 or so actually generates pretty good code. I can also tell you from experience that it is doable, it's just that you have hurdles to overcome that aren't present in C.
I would also add this: C++ compilers mangle symbols, which can be a bitch in linker scripts and other supporting infrastructure.
Aside from Linus' personal antipathy there are a couple of good reasons why you don't see a lot of other OS's written in it.
- It isn't that old. C++ is really only about 15 years old. That may sound old to today's typical Python programmer, but most OS's in existance have a codebase that goes back much further than that.
- Full blown C++ compilers are incredibly difficult to create. If you want to self-host your OS codebase, it's kind of a bummer to have to spend 11 man years on a side project to make your compiler.
- C++ isn't really designed for system's programming. It can do it fairly well, but that's mostly because it is built on C, which was designed for that.