Sorry, you do not know the language, and your statement is not credible. I think that C sucks.
On Wed, 26 Apr 2006, Jan-Benedict Glaw wrote:There's one _practical_ thing you need to keep in mind: you'll either
need 'C++'-clean kernel headers (to interface low-level kernel
functions) or a separate set of headers.
I suspect it would be easier to just do
extern "C" {
#include <linux/xyz.h>
...
}
instead of having anything really C++'aware in the headers.
If by "clean" you meant that the above works, then yeah, there might be _some_ cases where we use C++ keywords etc in the headers, but they should be pretty unusual and easy to fix.
The real problem with C++ for kernel modules is:
- the language just sucks. Sorry, but it does.
- some of the C features we use may or may not be usable from C++ (statement expressions?)Statement expressions are working fine in g++. The main difficulties are:
- the compilers are slower, and less reliable. This is _less_ of an issue these days than it used to be (at least the reliability part), but it's still true.G++ compiling heavy C++ is a bit slower than gcc. The g++ front end is reliable enough. Do you have a particular bug in mind?
- a lot of the C++ features just won't be supported sanely (ie the kernel infrastructure just doesn't do exceptions for C++, nor will it run any static constructors etc).A lot of C++ features are already supported sanely. You simply need to understand them. Especially templates and type checking. C++ exceptions are not very useful tool in kernels. Static constructor issue is trivial. I use all C++ features (except exceptions) in all projects: Linux kernel modules, embedded real-time applications, everywhere. They _really_ help a lot.
Anyway, it should all be doable. Not necessarily even very hard. But I doubt it's worth it.
Linus