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/
This archive was generated by hypermail 2b29 : Mon Oct 23 2000 - 21:00:20 EST