Actually I suggest the whole Linux FAQ because of many good explanations to questions like why isn't the linux kernel a microkernel and why aren't the gotos replaced with C style exceptions.
They give a pretty good answer to latter question - Admittedly, all those goto's do look a bit ugly. However, they are usually limited to error paths, and are used to reduce the amount of code required to perform cleanup operations. Replacing these with Politically Correct if-then-else blocks would require duplication of cleanup code. So switching to if-then-else blocks might be good Computer Science theory, but using goto's is good Engineering. Since the Linux kernel is one designed to be used, rather than to demonstrate theory, sound engineering principles take priority.
It is definitely a nice reading on a rainy afternoon
Sadly, I get the feeling that the FAQ - or, at least, this version of it - has been badly neglected. Many of the answers were written quite a while ago, rendering the answers misleading or just plain wrong. Many of the answers refer to 2.4 as the current "stable" kernel, dating them to 2004 or earlier.
It sounds like they took someone's patch, which renamed some identifiers to not conflict with the handful of new keywords added in C++, and ignored it.
I'd say the exact opposite. What is the point of replacing the conflicts with C++? Torvalds makes a very good case for not using C++ in the Linux kernel. At the very least, it seems like hiding memory allocation in kernel level code is a recipe for disaster. Of course, one could argue that you can use malloc in C++ just as well as in C, but then are you really writing C++? It seems as though you're writing C code in C++. In fact, many of the language "features" that C++ offers seem to be Very Bad Ideas(TM) in the kernel.
In addition, as Linus responded earlier, anyone who has written a modicum of C code knows that you don't need the complex language features of C++ to write modular, object oriented code (in fact, I'd argue that C++ is a blight upon OO and should probably die a horrible death, but that's neither here nor there).
Most notably, however, is simply that it is not the Linux team's responsibility to defend their use of C over C++ -- given the amount of code that must be adapted, it is more appropriate for the C++ devs to argue what heavy benefits C++ has in its favor (such that they merit the transformation of a complex and significantly large body of code).
I would actually say the C++ dev's view is more political than technical: advocating the switch to C++ "just because," implies a political (or religious) reasoning, while the Linux team's view seems much more technical.
As someone who has done some seriously low-latency projects on C++, there are really many levels that you can do this at. You can turn off exceptions, do constructors very sparingly, handle your own memory management and so on. As was said by its creator, C++ is a multi-paradigm programming language.
There is something to be said for doing a lot of kernel stuff in template metaprogramming.
(Could've sworn this was in C++ FAQ Lite, but I can't find it) The language specifies exceptions as a feature, not an option. Turning off a language feature and how that works with other features that may reference it is a heavily compiler-specific endeavor, and isn't C++.
Yes, you are correct. In my high-performance version, I used an extension of the language provided by g++ which allowed turning off of exceptions, which sadly cost time even if you don't use them.
There already are projects that run C++ code in the Linux kernel; the Click Modular Router from MIT PDOS is C++, for instance. It's probably prohibitively annoying to write mainline kernel code, like a device driver, in C++. There might not be anything to prevent you from loading a whole C++ subsystem, though.
I'll head some other commenters off at the past and note that MacOS X xnu has a C++ device driver interface, but is still a C-code kernel.
Linus is right about the exception handling and allocator issues. C++ exceptions are a misfeature in userland code; it's even more important for kernel code to be able to handle problems gracefully and explicitly, and unwinding stacks through functions running at different interrupt sensitivities and holding different locks seems like an disaster waiting to happen. And, unless my C++ has gotten rusty since Alexandrescu's book came out, nobody likes the C++ allocator interfaces --- which you'd certainly have to dive into to handle the kernel's various different allocation strategies.
Why was this downvoted? He has a differing viewpoint, but I think its a compelling argument. Not altogether off-topic either (especially when you consider people talking about implementing OS kernels in things like Java or D).
I learned OOP in Smalltalk. Then I decided to learn C++. The first code snippet I saw used the overloaded shift operator to push strings to stdout. I closed the book.
It took me 8 years to try to learn C++ for a second time. This time I insisted and more or less got through.
C++ is not as bad as my first impression led me to believe, but it's not as good as its enthusiasts insist it is. For instance, and quite predictably for a Smalltalker, I find Objective-C much more elegant.
It seems foolish to implement something like this in C++
Ugh, old, old FUD from years back (not you, the article). g++ (the only C++ compiler that's relevant) has been as fast as gcc for years (they use the same back-end).
<rant ignore="recommended">
Frankly the quick reason is that the kernel is a hobby for many, and a fetish for some. Engineering decisions are made at the geek level, not a management level, e.g., "This cool hack will make it faster for the $250k big-iron box I got on eBay" vs "We should put together a unified infrastructure for making 802.11 easy to use."
</rant>
<sidebar title="Linux on C++ Patch">
The work I mentioned above (to the side?) was an effort to make the kernel compile on g++. They also made exception handling faster than printk(). Like it or not, a lot of techniques used in a "modern" unix kernel are language features in C++, e.g., vnodes/vtables. On top of that, exceptions provide a much more structured way to describe (via an entire type system, not just error codes!) and handle (catch what's relevant to you, pass on what's not) errors, with the ability to automatically clean up resources and state along the way (local variable destructors, the 'operate-and-swap' idiom for stl containers).
But no, all we have is ~15 yr old FUD quoted over and over, ironically similar to the windows users they love to complain about.
</sidebar>
> Ugh, old, old FUD from years back (not you, the article). g++ (the only C++ compiler that's relevant) has been as fast as gcc for years (they use the same back-end).
g++'s generated code is not as fast as gcc's, despite their common infrastructure. For the last month or two, gcc has been compilable with g++ as well (it has been rewritten in the common C/C++ subset), and the reports are of about a 10% decrease in speed when compiling with g++.
In reality any C++ code can (and it's internally) translated to C one (that's called the front-end compiler). The back-end is the same.
The only difference is when there are things required by the C++ runtime (mainly exceptions and RTTI, and in some sense virtual functions).
I'm sure that if you take a "C" code, and compile it under "C++" compiler (given that it can compile) - you won't see difference.
Please disassemble it, and see for yourself.
That's the other problem with C++ - no one actually for real writes in full C++ - you always end up sacrificing features (exceptions most notably) to have running on embedded systems, or game consoles. And no RTTI there too.
For example if you have exceptions enabled, there must be some infrastructure for handling them. Certain C++ compilers generate almost no code for handling exceptions, but the handling is expensive. Other compensate that with more generated code (for keeping stack frames), and faster handling.
So you can say - well - disable the exceptions.... But is that C++ anymore?
For example Common Lisp is multi-paradigm, but there is no Common Lisp without CLOS. It can't be disabled, and still call itself Common Lisp.
Same with RTTI in C++ - it's in the language, but again it can be disabled. Or new/delete (and the missing reallocate construct).
So C++ the language, and C++ the runtime being used are quite different things when comes to usage.
