DragonFly kernel List (threaded) for 2003-07
Peter Dufault wrote:
Did you consider using a subset of C++ for the kernel?
I'm not Matt, but my thoughts would be:
1. C++ is too "heavy". There are much more lightweight
C object systems than the "big two" (C++ and
2. C++ changes the namespace semantics too much and spends
too much effort on hiding the changes from the programmer,
with the result that integrating anything else into C++
is pretty hard.
3. Using formal object mechanisms for shims and proxies makes
it too hard to install them later on. Most of the work
involved isn't just juggling the two or three function
pointers in a message struct (which is where C++ would
come in) but in handling the concurrency.
4. The same message handling mechanisms are used inside and
outside the kernel, so once you have C++ involved you
pretty much have to commit to C++ wrappers for everything,
or making C++ the system programming language.
I think that a better course of action is to keep on top of
the message/method design while it's being developed, and
head things off where something gets too complex: find common
hooks and use them instead, repartition responsibilities when
some subsystem or some mechanism is doing too many different
things (can you say ioctl?), and so on.