C++

[Peter da Silva]

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
     Objective C).
  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.