I have to disagree here. Overloading `new' and `delete' per object
type, with a good allocator (e.g., the kernel's slab allocator) can
result in *excellent* memory allocation performance. One obvious thing
is that the choice of allocator, bucket etc. can be resolved at compile
time. That is enough to make many allocation & free calls just a few
inline instructions, with occasional out of line calls. It is very
fast, and for some allocation patterns very memory efficient.
Of course, the kernel already does this for the critical structures, so
there's no need for C++.
> The problem with C++ is not the compiler, it's the language. It encourages
> you to make things opaque. It wants you to do things quietly behind the
> scenes. It wants you to use constructors, deconstructors, dynamic memory,
> copy constructors, inheritance, overloaded assignment operators, temporary
> objects, virtual functions, etc. All of these things can suck performance
> and fatten code in ways that aren't obvious from staring at the code.
Unless you're a real C++ expert. Sometimes it can make the code
thinner, by dint of clever type inference, and clever compile-time
transformations with templates. I admit this is rare and difficult.
> The kernel could be rewritten with C++ and objects to be as fast as it is
> now, and probably quite a bit cleaner.
I disagree. The kernel does many things that would naturally get
expressed in C++ as objects -- especially the function pointer stuff,
and some of the unions. However the existing C mechanisms are in some
cases faster than they would be in C++.
> Such a rewrite would probably take
> years to do _right_, and would take more design discipline than I've ever
> seen on a project of that size. Not worth it.
I've seen the required design discipline. It said "no" to C++...
> One day, computer power will eventually outstrip demand, and OS engineers
> will be free to use friendly languages like LISP again.. until then, I
> think we're stuck with C.
When that happens, it'll probably outstrip the demand for a kernel, too.
-- Jamie
-
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/