Getting the Linux kernel to compile using a C++ compiler is a considerably different activity than switching the language of the kernel to C++.
I'm in the middle of trying to figure out how to fix bugs in an old C++ MFC program that does real-time communications. These are my current problems with C++:
1. Estimating the performance of C++ code. For example, what does a simple statement like A = B do? In C, you can kind of answer that question. In C++, anything can happen. I have debugged libraries that specifically say A=B will not leak memory, and it does.
2. Which version of C++? The C++ standards committee has been really busy lately ...
3. Unlike the preprocessor, the template generator does not dump in the intermediate C++ code. One of the nice features of the C preprocessor was that if you didn't understand what it was doing, it could dump its output as C code. The MS C++ compiler generates a small book of error messages if I goof up type indications when using templates, and those messages don't clearly suggest a fix.
4. If you are trying to do solid, multi-threaded, real-time code, C++ doesn't help you. It doesn't stop you. But it doesn't help you either.
5. If you are still trying to do multi-threaded code, and follow the entire shared_pointer (not thread safe), atomic_shared_pointer (slow, possibly locking), hazard pointer (lock-free), fast shared pointer over hazard pointer discussion (multi-threaded and lock-free), then you realize two things:
(a) this is a new way to do garbage collection (C#/Java), and
(b) the new fast hazard / shared pointers are too new to be in the C++ library!
5. It's almost impossible to write readable C++ code without a style guide. The style guide will always be out-of-date. How do you enforce the style guide on a project of the size, scope and age of Linux? or any other long-lived project?
6. Correctness: how do you analyze code correctness in C++?
(a) It is not obvious what any given statement does.
(b) It is not obvious what the maximum execution time of a block of code is.
(c) It is not obvious that any given pointer is valid.
(d) It is not obvious that smart pointer accesses are wait-free.
(e) Even if you get all of your pointers to be valid, it is not obvious that libraries won't create indeterminate state or suddenly call exit(). This is a real problem. We have user complaints like "I clicked on this button to enter a number and the program disappeared." We traced it to a library, which does something, which does something, which has an error condition, and terminates in an exit(). Our program is a real-time control system. It can't give up and call exit().
(f) For long-lived applications, C++ works great as long as you can guarantee the program can handle all of the exceptions that it can throw. Does C++ help you do that? Can I even get a listing of all of the unhandled exceptions? or which exceptions are handled where?
(g) Real-time control systems need to execute in finite memory. Much of the C++ library assumes that an unlimited heap is available.
7. Would it be too much to ask for a safe array type? Something that handles a[-1] gracefully? My PLC structured text compiler throws error messages if I even enter such a thing. It will never cause a GPF on an invalid array access. What standard data type in C++ does something similar?
8. Can we have a safe multi-threaded variable length array type, please?
Is C++ even the correct language for a large program like the Linux kernel?