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.
If you want to know why C++ sucks for operating systems design, look at COM.
A fool and his hard drive are soon parted.
If you want to know why C++ sucks for operating systems design, look at COM.
If you want to know why C++ is great for operating systems design, look at the Amiga Exec.
Which actually was written in C, but mapped flawlessly onto C++.
COM isn't object-oriented. You never actually had a handle on the object itself, just an interface.
Good C++ is just as fast as good C, and easier for the programmer to optimize. Compiler optimization is on the same level. C++ even allows some interesting things like zero-cost error handling that is actually impossible in C.
C++ is an enormously powerful and comprehensive language, and it relies on the programmer or organization to use a reasonable subset of it and use good judgement in applying any given feature. I would grant that poorly written C++ is probably much worse to detangle than poorly written C. However, well written C++ is just as usable and maintainable as well written C. More critically, C++ interfaces and methods can be written in such a manner as to provide much better protection to the programmer from his own mistakes. It's much harder to do that in C. In today's security-conscious world, where a single mistake can mean a critical OS vunerability, that's a real issue.
Essentially, C++ is C plus the ability to create powerful abstractions, typically expressed in objects/classes and templates, but not necessarily limited to those. Those abstractions put more of a burden on the compiler rather than the programmer, and as a result, is much safer than anything one could write by hand. All raw memory buffer manipulation, for instance, can be done through carefully protected wrapper objects or other user-defined primitives, and there's no reason in modern C++ to manipulate object lifetime through raw pointers, as it now has standardized smart pointers. Any resource - memory, file, locks, handle, etc, should be lifetime managed by objects - and so modern C++ should feel a lot like a garbage-collected language. In fact, I'd say it's superior to a garbage collected language in many respects, because garbage collection is not nearly as predictable as object scope rules, and doesn't extend quite as nicely to non-memory resource management (e.g. IDisposable in C#).
It's certainly not a language suitable for all tasks, and it arguably requires more expertise than C to use it well. However, systems programming is absolutely one of those things it's well suited for. Binary compatibility would be great to have, but is not a real hurdle. To work around it, you can simply fall back to a C-like API at module boundaries, and avoid passing any objects across. That's what I typically do when I have to write C# C++ interop layers, and it's worked pretty well for me. While it brings along a lot of cruft, C compatibility, including it's binary compatibility, is one of C++'s great strengths as a language.
Irony: Agile development has too much intertia to be abandoned now.
I'm sure everyone will believe your theory that linus just can't grasp C++'s advantages and that's the reason why he doesn't want to rewrite the entire kernel in C++
C++ object can be linked with C code, I have used that ability to add C++ code incrementally to projects originally developed in C. As a result, have had plenty of opportunity to compare the C++ result to the original C. Typically, equivalent or identical object code but source is more consise, readable and maintainable.
When all you have is a hammer, every problem starts to look like a thumb.
In fact, I'd say it's superior to a garbage collected language in many respects, because garbage collection is not nearly as predictable as object scope rules, and doesn't extend quite as nicely to non-memory resource management
The importance of this is underestimated. With a sanely written C++ program (merely sticking to the modern approaches) memory and resource leaks are a thing of the past, but you still get the completely predictable and deterministic resource management of C.
I'm sadly working with Java services now, and we have a seriously problem in that there's no reasonable way to tell that a Java program is getting close to crashing due to memory exhaustion. In C++, you can just monitor heap size, and alarm based on values and trends and all that good predictive jazz. In Java, even with the better garbage collector designed for servers, "bouncing off the roof" is the norm, and it's quite hard to tell when danger is approaching.
I'd be interested in any /.er advice here - is there some dependable way with Oracle Java to measure "real heap size" - the total size of objects actually in use? The better garbage collector for servers (G1) never pauses the world to free everything it can, so it's not like you can look at post-collection heap size or anything.
Socialism: a lie told by totalitarians and believed by fools.
And I wouldn't say that C++ adds much to maintainability -
Actually, it does, by giving you abstractions instead of you having to write them yourself as you do in C. In the embedded world, there's a term: "C with classes": this is when C++ is used on embedded systems, but only a small subset of C++. The code looks pretty much just like C, but there's classes and inheritance, but many other things are specifically omitted, such as exceptions. In aviation (DO-178), there's standards for using C++ in avionics systems, and here again, they specifically forbid the use of many C++ features which prevent determinism, such as exceptions.
If anyone's going to write a kernel in C++, they should just follow the FAA DO-178 standards.
I've had to maintain some real winners of C code where the programmer went hog-wild with macros. UGH.
I sympathise, my first experience writing commercial code in C++ was in the early 90's with the Watcom compiler of the day. Their implementation of C++ was not part of the language, it was a complex layer of C macros that served as wrappers for goto statements, function pointers, etc. I had learnt about OO concepts from smalltalk a couple of years earlier while studying for my degree, the Watcom macros were what I'd call a "sociopathic implementation" of some of those ideas.
The mistake Watcom made back then is the same one many developers are still making today - "object orientated" is not a language feature, a layer of macros, or a bunch of library calls, it's a powerful and ubiquitous design methodology.
For example, if you look carefully at the examples in K&R's "C programming language", most are excellent demonstrations of OO design that were written long before the term "OO" was invented. The elegance that many developer's perceive in K&R's famous examples is not in the syntax, it's in their design.
Next up - "Spaghetti code" is not a language feature.
And did you exchange a walk on part in the war for a lead role in a cage? - Pink Floyd.
It's not about what Linus wants, it's about what it takes to keep project relevant by attracting talented new developers. There is no way I am doing new work, especially an unpaid hobby project, using plain C in 2014. Automatic destructors and templates would be a step in the right direction, but what we really need is to be able to write user mode device drivers in Java and Python. They will suck, no doubt, but far less than not being able to use the hardware at all. In the end, perhaps Linus should have listened more to Andrew Tanenbaum. With less monolithic OS, people would be able to write key services in any language they want.
The C++ compiler will most certainly be less buggy than something thrown together to cover some element that C lacks.
Unfortunately, C++ includes an explicit non-standard that can inject subtle bugs. This has been present since at least 1988, and has survived at least the first two standards (after which I stopped watching, having moved on to mostly hardware design).
(I DID try to bring it to the attention of the standards committee in both cycles, but it was ignored. Bjarne, in his recent Slashdot Q&A, didn't answer my question on it, either.)
The problem relates to which overriding of a virtual function is called during the initialization of the member variables and the construction of member objects of a derived class (and the corresponding destruction of the member objects during the destructor). The standard permits the calling of the derived class' version of virtual member functions at this time, when the derived class has not initialized, or has dismantled, their underpinning.
Compilers are permitted to cause the call to go to either the base class version (IMHO correct) or the derived class version (IMHO dangerously incorrect). Calling the derived class version is bad, preventing a number of obvious constructions from working as expected, imposing limits on what programming techniques can be used safely, and displaying no warning (so the programmer has to know what not to do). Letting different compilers make different choices is horribly worse, as it makes the behavior unpredictable and compiler dependent.
C++ (especially the early versions, before it became buried in libraries and baroque constructions) came SO close to being a powerful and reliable tool for rapidly writing reliable code on large projects. But this "little bug" brought it all crashing down.
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way