"Linux Kernel Developer" <linux_developer@hotmail.com> said:
> Wasn't the original complaint that the kernel headers use C++ keyword
> and thus prevent the writing of, at least some, modules in C++. I have
> written C++ code before that was as least as fast as comparable C code and
> more efficient in some ways. Whether this could be or not be reproduced in
> kernel code I do not know. So far I have done my kernel programming in C.
> However even if I or other programmers would like to give this a try it is
> my understanding we cannot because of the header situation. I think it is
> unfair to attack C++ kernel code that is unable to come into existence, at
> least without jumping through a bunch of hoops, due to external influences
> (i.e. the incompatible headers).
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...
> On a separate note. Isn't one of the philosophies behind Linux the idea
> of freedom.
"Freedom" as in "you are free to do what you want" and "you are free to
suggest whatever you want". Not free as in "feel free to suggest anything,
we'll bend over backwards to please you".
> If people wish to try and program their modules in C++ for
> whatever reason, be it porting from existing code or to object orient their
> code, should they be free to do so.
Linux _is_ object-oriented. Much more so than most C++ programs I've seen.
> If the header situation is true, which
> I am not sure of since I have not tried to do C++ programming in kernel
> code, then people aren't free to write modules however they wished.
But they are! It is just a fact of Linux that by writing them in plain C it
is easier to do than in C++, FORTRAN or Emacs LISP. You can't expect the
head kernel hackers to devote their (precious, and probably way too little)
hacking time to create this kind of infrastructure for the lazy few.
> Seeing
> as fixing the headers should be rather trivial and probably is the right
> thing to do anyway (using existing language keywords is a bad idea) I do not
> see why this same flame war must erupt every time the header situation is
> brought up.
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.
-- Horst von Brand vonbrand@sleipnir.valparaiso.cl Casilla 9G, Vin~a del Mar, Chile +56 32 672616 - 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:19 EST