Slashdot Mirror
Object Oriented Linux Kernel With C++ Driver Support
An anonymous reader writes: An effort underway called BOSS-MOOL, the Minimalistic Object Oriented Linux, is designing the Linux kernel with OOP and C++ driver support. Linus Torvalds' opinions on C++ have long been known while developers at the DOS Lab IIT Madras and CDAC Chennai feel redesigning the kernel with object oriented abstractions and C++ driver support will increase maintainability while reducing complexity of the kernel. It doesn't appear though the group will try to mainline these changes.
BeOS used C++. Microsoft Windows uses C++ -- albeit with the CRT (C Run Time) library separated.
Linus hates C++ for kernel development because C++ can't guarantee a binary API from one compiler to the next due to shitty non-standardized name mangling. The C++ committee would rather add a 2D graphics API that no one cares about to the language libs then focus on binary compatibility.
One of the real powerful things about C, especially for writing an operating system, is that a good C programmer can look at a piece of C code and have a pretty good idea of the machine code being generated. In the presence of C++ inline functions, implicit type converters, copy constructors, and assignment operator overloads that ability goes right out the window. If you were managing a project that involved lots of small contributions from a large and widely distributed group of developers that inability to see what a small patch does would be fatal.
On a more subtle level, C++ rewards a well-thought out design that doesn't change very much, and mercilessly punishes a design that is produced incrementally in an evolutionary fashion. Given how Linux has developed over the years, C++ would have been a brutally punishing language for Linux.
I like C++, I've used C++ in quite a few projects. I will probably use C++ again. But I can easily see why the Linux kernel is not a great place to use C++.
Every sufficiently large C project re-invents key portions of C++, poorly. I've been involved with a couple such efforts myself. There's just no excuse for the NIH-ism. The C++ compiler will most certainly be less buggy than something thrown together to cover some element that C lacks.
Socialism: a lie told by totalitarians and believed by fools.
Because the compiler cannot guarantee correctness. That you think so is what make C++ and C++ developers so dangerous, especially in kernel space.
The only thing C++ solves in kernel development are problems that nobody cares about. Replacing macros with templates and long function names with namespaces buys the kernel developers precisely nothing.
Is C++ going to solve RCU and complex atomicity issues? Is C++ going to make run-time dynamic code generation easier? (That is, replacing NOP instructions at boot time for optimization and debugging.) No. In fact, C++ is worse for these things because C++ does too much implicitly, which makes it harder to reason about the code.
Before you opine on why C++ is better, why don't you download the C++11 and C11 specifications and read them thoroughly. Then contemplate how you'd write implementations for those. Then reassess how much, exactly, C++ simplifies anything.
Too many developers believe that as long as you _hide_ complexity, it has no cost. If it doesn't look complex on its face, how could it possibly hurt? Or by ignoring a feature you think it's magically disappeared. That's wrong on so many levels that it's difficult to even have a rational conversation with people who think that way.
Having been on the fence about this for a while, my experiences convinced me that C++ is wrong for the kernel.
The problem is not the extra features. The problem is that the programmer has little control over exactly how they are implemented: the compiler decides how to handle virtual method tables, destructors, multiple inheritence, etc. In the recent past, C compiler bugs have caused serious problems with Linux development. C++ compilation is an order of magnitude more complex, and you can bet it would be less reliable. This also means that C++ compiles much slower: doesn't sound like a big deal, but it is a cost to take into account.
The lack of a standard, clear ABI for C++ is also problematic. While it's true that Linux is monolithic, it still supports modules that interact with each other dynamically. Debugging C++ can be quite painful because of this. But it also means that it would be that much harder to contribute a module if it's not written exactly for the same compiler as the one used to build the kernel. Of course, it would have to be written in C++, too. This lack of flexibility can be quite painful in environments where you are limited to very specialized compilers (embedded). C has the most standard ABI of any language (well, C and Pascal). You can guarantee that *anything* would be able to interface with it.
So if you put the technical cons (losing control, flexibility and debugabbility) vs. the pros (cleaner syntax) then it's right to pick C, on technical grounds. As others have stated here, anything you can do in C++ you can do in plain C. It's a bit clumsier, but then you have complete control over the implementation. I do OOP in C all the time, it's perfectly OK. If anything, a bit more powerful than C++, because I tailor the OOP features to exactly my needs and tastes.
Beyond that, there is the more controversial issue of programmer culture. C++ hides away implementation details, but for kernel development you want programmers who think about every tiny issue of implementation: exactly what is going on with the call stack, what is a pointer and what isn't? The more explicit nature of C encourages a more hard-nosed stickler for technical correctness, which is more important than pretty code for kernel work.
By the way, I'm writing this as a former C++ zealot. I even created something like this in the past, a C++ wrapper for Windows NT networking services. I found out the hard way that C++ takes more than it gives. I write all my code in C these days, and don't feel like I'm missing anything.