[...]
> I can see at least some good uses. Start by using it as a better C, strong
> type checking, etc. Perhaps use some of its features to get rid of fancy
> uses of preprocessor macros, which are usually somewhat cryptic.
I don't see what can be done in C++ that can't be done in GNU C (this is
definitely not ANSI C!) in this area.
> Port
> various structures to classes. The programming of modules may be especially
> enhanced, perhaps by having all modules inherit from a generic module. Even
> better this would allow for easy changes of different parts of the kernel,
> like interchangable parts. For example, choose from different memory
> managers when cutomizing your kernel. Perhaps one optimize for low memory
> systems, another for normal users, and yet another for those who must have 4
> Gigs. If each MM is derived from a common virtual parent, this cound even
> be doable at runtime. Or perhaps you want to be able to choose amoung
> differing disk caches. This could definately be very useful.
The kernel is one huge, carefully object-oriented design. Ever seen the
structs full of function pointers? That's your objects and virtual
functions, written in C. Plus the kernel does stuff that _can't_ be
(cleanly?) expressed in C++: Call this fallback function if the specific
function doesn't exist, or fails. Change the function to be called at
runtime.
That these other things you ask for don't exist as separate entities is
because (a) it is harder to write and maintain 3 different memory managers,
for instance. Heck, even _one_ gives the head hackers headache!, (b) it is
often easier to write _one_ version of something that adjusts to different
circumstances than several rigid ones. (c) It is way more flexible. For
example, "low memory" is somebody's 8Mb machine all the time, or some 128Mb
machine under peak load. You'd want the MM to adjust, not to be wired in at
boot or configuration time, and you want it to do it on its own, not by
sysadmin intervention. And (d), Linus has strongly stated here and
elsewhere that he _won't_ _ever_ accept such bloat into the kernel. Mostly
by (a) to (c).
The first rule of good design is that it is the one from which nothing can
be taken away, not the one to which nothing could be added. Look at some
of the competition, they traded a few % here for a nice feature there, and
another % there for this nifty addition, and now they are a unholy mess.
> >language just offers too much over plain C and was designed specifically
> >with large-scale systems programming in mind. The biggest limitation to
> >full adoption of C++ that I've seen is the whole ABI/method call
> >convention/name mangling fiasco which I feel really should have been
> >addressed by the ANSI committee (at least guidelines and suggestions for
> >future standardization).
Name mangling is just an internal detail, and everybody mangles differently
on purpose because the internal interfaces are different. If they did not,
you'd be able to link together stuff from different compilers, and the
resulting executable won't ever get off the ground.
The thing that killed C++ is that the language still changes daily. The
language is _hugely_ complex, hard to get right for compilers and
programmers. It also has many hidden surprises performance-wise.
-- Dr. Horst H. von Brand mailto:vonbrand@inf.utfsm.cl Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513- 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/