views:

1245

answers:

9

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?

+23  A: 

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

artknish
+! Nice link/rant. :)
cletus
Dude, clear words! But still the opinion of a single person, albeit an opinion with weight.
prinzdezibel
mixedpickles, Since Linus wrote the kernel at first, I think we can get a good idea why the kernel were written in C and not C++ from the posts he writes about GIT.
martiert
It's the opinion of the person who started the kernel. As such, I think his decision is, and was, final.
jalf
A: 

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.

Stuart
These tests beg to differ (most in speed, some in size)http://shootout.alioth.debian.org/u32q/c.php
heeen
They show the memory usage is far lower from not having objects, and the execution time is comparable.
Stuart
No, this assertion is flat out wrong. Modern C++ compilers usually produce code without object overhead. In fact, good C++ will be faster than equally good C for reasons to do with inlining (function pointers can't be inlined, function objects can!)
Konrad Rudolph
Function pointers can be inlined in C.
Stuart
Calls via function pointer usually cannot be inlined - whether it is C or C++. If the situaiton allows it for C, it can be done for C++.
peterchen
Function pointers can only be inlined in the general case if expensive global optimizations are performed. Function objects in C++ are trivially inlined. Also, what is this overhead of objects that you speak of? Care to elaborate? Which magic "pleaseslowthisdown()" function is called?
jalf
Template metaprogramming anyone? Saying C is faster than C++ is a non-sense.
Edouard A.
Re: jalfYou really don't know how objects have overheads? I hope you're just being facetious.
Stuart
Stuart: listen to jalf. Objects generall do *not* have overhead. It's as simple as that. Only specific use cases (e.g. virtual function calls) do actually impose any overhead.
Konrad Rudolph
Wow. This answer sure got dogpiled. I'd suggest googling yourself up some actual numbers.
T.E.D.
+2  A: 

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.

JoelFan
I think you're confusing design and actuality. C is a good language for OS development; the question here is whether C++ would be a better one. If you're looking at design intent, C++ was designed as a better C.
David Thornley
Not exactly... parts of C++ were, as you said, to make a "better C" but most of it, such as object orientation, were a departure from C in that the mapping to assembly language was much less straightforward. The "better than C" features of early C++ were mostly incorporated into ANSI C.
JoelFan
+54  A: 

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.

Richard Wolf
This is probably one of the most balanced and constructive posts I've read on this topic, +1 for you. (Especially when compared to the git debate which appears to revolve around: "all C++ programmers are idiots, all C programmers are experts").
Richard Corden
Good posts. however I'd like to see some actual numbers on C++ is slower than C. I've given a link to this site http://shootout.alioth.debian.org/u32q/c.php in a comment a few posts down, but nobody seemed to take notice.
heeen
A: 

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."

E Dominique
Ah, before C++ was actually standardized, much less a reasonably useful language. Trust Linus to use *that* as justification. (There are good reasons to avoid C++ in low-level kernel code, of course. But "C++ sucked 7 years before it was finalized" is not among them)
jalf
Yeah, I often find that people who say "C++ sucks" are still talking about MSVC6 or some other terrible implementation of it. Yes, there are good reasons to avoid C++ in kernel code, but avoiding it because of what C++ was fifteen years ago is stupid.
Kristopher Johnson
Well, considering that we are still *using* MSVC6 here, that hardly helps me. (Yes, it does suck).
T.E.D.
A: 

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:
Vinay
+4  A: 

The Fiasco micro kernel is implemented in C++.

EricSchaefer
So C++ is a good choice if you want to create a Fiasco? :-)
T.E.D.
I can even create a fiasco with any language!
EricSchaefer
this such a bummer.
gokoon
+2  A: 

@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.

Ben Collins
+2  A: 

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.

  1. 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.
  2. 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.
  3. 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.
T.E.D.
From Stroustrup's glossary: "C++ - a general-purpose programming language with a bias towards systems programming..."
Richard Wolf
"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." that'S BS. sorry but that's one of C++'s primary goal :)
Johannes Schaub - litb