>
> Ok, those are good temporary reasons to not use C++. Those problems
> should improve or eliminate themselves over time, when we might want to
> change our minds. But until then, how about making the kernel
> _compilable_ under C++? The advantages in the stronger type checking
> alone should be more than enough reason to periodically compile the
> kernel w/ g++ to make sure there aren't any subtle type errors. In a
> project like this where everyone's submitting patches randomly, it is a
> good safety measure. There's even a chance it could improve some code
> by pointing out which parameters weren't used in a function. While it
> doesn't guarantee good code, it does prevent sloppy code from causing
> problems.
>
Most of the extra checking that C++ does is done when the GCC -Wall is
used.
IMO, the big drawback to _really_ using C++ is the fact that C++ is much
harder to truly understand, especially when looking at a small part of a huge
project (like the Linux kernel). With C you can look at an isolated function
and pretty much know exactly what it is doing (assuming sane use of #defines
and perhaps with a few "greps"). With C++ you really have no clue what the
function is doing without recursivly looking at a bunch of class definitions
and header files to determine which operators are overloaded and what the
member functions actually do. Of course, with proper identifiers and good
comments both languages can be understandable but with C++ it takes a lot
more effort (especially in the design phase, which is ongoing and distributed
for Linux).
I have had to port a large C++ project (printout was about a foot thick) to a
different platform with many design changes and it wasn't at all fun. I
resorted to looking at the disassembly of functions in a debugger to find out
what the program was actually doing and get a clue as to where to look for
problems. This is of course only one example (and a DOS game no less,
"FPS:Football '94") but I think many people don't understand what can happen
to a "clean" C++ design when people in the real world have to make things
actually work (and that the design missed). The Linux kernel development
would probably be a worst case because of the limited bandwidth of
communication of "headspace" between developers.
When designing a C++ project from the ground up with C++ experts having a
good knowledge of all the classes to be used, C++ can make development easier
(for some, I've not quite seen that happen myself). But with Linux you have
a large distributed programming project that is evolving rapidly from the
work of people with typically only intimate knowledge of a small piece of the
overall project.
I think kernels belong in C (if you are not using assembly, that is :-).
Ken Jordan
P.S. I'm not actually worried that the kernel will be redone in the C++
paradigm anytime soon. But this question comes up every few months or so.