Why don't we rewrite the Linux kernel in C++?
tux.org
tux.org
However, the points in the OP linked article make a lot more sense to me than some Linus rant.
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
Then they bragged about it.
That seems to be more political than technical.
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.
There is something to be said for doing a lot of kernel stuff in template metaprogramming.
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.
JWZ - The worse is better.
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++
Remember the C# one came on HN? http://daeken.com/renraku-future-os
I think an OS written in an OO language will demonstrate why some people were actually worried about OOP. http://www.geocities.com/tablizer/oopbad.htm
After this was released: http://developers.slashdot.org/article.pl?sid=04/10/27/21102... (the original link is lost, but I'll summarize below), and the community ignored it, I stopped really respecting the technical merits of the Linux community. It's a hacker's hobby that became good enough in a group of systems that stagnated (see http://doc.cat-v.org/bell_labs/utah2000/ ).
<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>
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++.
(g++ vs gcc in the language shootout).
I'm gonna guess gcc's been optimized for compilation by gcc (or at least the bootstrap version), and that no such optimization's been done for 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.
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.