Messages in this thread | | | Date | Tue, 06 Jul 1999 14:33:14 -0700 | From | "Nate Tuck" <> | Subject | Re: linux headers and C++ |
| |
At 09:27 PM 7/6/99 +0100, Alan Cox wrote: >The second one is that it wants to >use new and destroy. You can provide your own new/destroy wrappers using >the kmalloc/kfree functions although you have to be careful to handle failure >cases. The conventional C++ "out of memory" message and quit wont cut it in >a kernel.
new should throw bad_alloc if it fails to allocate memory. If you catch and rethrow exceptions properly you can do all the standard releasing of mutexes, deallocating allocated memory, etc, that you would do in kernel C code when you failed a malloc. I'm assuming that any implementation of C++ in the kernel would already have new/delete and other intrinsic functionality rewritten in terms of standard kernel resource allocation mechanisms.
The real problem is that writing good C++ code requires more discipline than writing good C code (because the language gives you so many new and exciting ways to shoot yourself in the foot), and putting it in the kernel is going to add even more constraints that even good C++ programmers may not see immediately.
There may be some good reasons enough to keep C++ out of the kernel, but appeals to common practice with things like "using feature X induces bloat" or "most C++ programs don't handle OOM the way the kernel does" really don't count for much in these kinds of arguments. Kernel C++ would have it's own style that differs from C++ just as kernel C looks different to userland C.
The primary reason I can see to keep C++ out of the kernel is that the user base doesn't seem to be large enough to get over the initial barrier of making it work and supporting it yet. If it were, the necessary patches would already be in doubters hands and none of us would be wasting bandwidth on the subject.
nate
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |