Messages in this thread |  | | From | "Linux Kernel Developer" <> | Subject | Possible C++ safe header project - Re: [Criticism] On the discussion about C++ modules | Date | Mon, 23 Oct 2000 08:47:53 -0400 |
| |
OK I've decided to give this a shot, IF there is sufficient interest out there for C++ safe headers. So all you coders out there who have tried and failed or who wish to program kernel modules in C++ join in and help out by listing the errors you have encountered with the current header setup.
This is currently what I plan to do to make safe headers.
1. Insert
#ifdef __cplusplus extern "C" { #endif
at the begining of each header file and
#ifdef __cplusplus } #endif
at the end of each header file.
2. In the files which contain the usable of C++ keywords I intend to use define statements such as the one below for the offending keywords:
#ifdef __cplusplus #define class lk_class #defined new lk_new .. #endif
A side effect of this is that certain kernel variables make have to be accessed in a C++ module with a new lk_ prefix. However C code will not be affected. I don't like the idea of using the define statements especially after seeing the horror Palm did in their SDK however I cannot think of another way to transparently fix this unless the offending header code is self contained. If anyone has a better idea let me know.
3. Add a new header for C++ modules that currently only include definitions for the new and delete operator functions. This should be simple enougth. Basically map new to kmalloc and delete to kfree. new will be a non-exception version that returns NULL on error just like it used to do before the horrible new C++ standard. I'm not even going to go near exceptions as that IMHO creates non-clear and hard to debug execution paths in code.
Please comment on the pluses and minuses of each planned task and on other things that you may see that should be done. Please no flames unless they contain useful information. Also I plan to implement the first patches for 2.2.x. I prefer to work on a stable codebase at least while the project gets off the ground. The other thing I'd like to know if the eventual patch, if there is any as this is dependant on interest, would be considered for inclusion into the standard source base.
Let the games begin.
> The "incompatible headers" can be cured mostly with just: > > extern "C" { > #define new header_new > #define ... > #include <c-header.h> > #undef new > #undef ... > } > > If they can't go this far, or create a local patch for the offending > headers (perhaps even suggesting it for inclusion) I don't see why they > should even be considered, not to mention taken seriously... > > Fix it, send in a patch and get over it. Given your email address, this > should be a no-brainer for you. At the very least, such a patch will > (hopefully) stop this nonsense. > > > Its not as if C++ code would all of the sudden popup in the > > kernel core forcing everybody to use C++. At best a driver here and there > > might start using it and its continual usage would depend on if its > > implementation is successful or not. And those drivers themselves are > > extremely likely to be self-contained thus not affecting anybody else's > > kernel code. > > I'd prefer the kernel staying plain C, with no admixtures. Just MHO, of > course. What somebody else does in the privacy of their own trees is their > bussiness, as always.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
|  |