C++ in the kernel

[Ivan Voras]

On 29/10/2007, Poul-Henning Kamp <phk at phk.freebsd.dk> wrote:
> For instance, the entire "dual-address space" dictomy og system
> calls/copy{in,out} and the very concept of interrupts are very
> tricky to sensibly express in anything but C.

I don't see those example as something special or different - they are
just "there" to implement with or around. Copyin/out can be
implemented as-is, literally in C, or it can be abstracted (and C++
isn't a good candidate for this, AFAIK it lacks proper "properties" -
members that cause function invocations in the form of getters/setters
- see Object Pascal, C#, Python, etc.). On the lowest level,
interrupts are just function invocations triggered externally, by
hardware. Any language that can give you a pointer to a function can
handle those. There is no reason not to implement the kernel in e.g.
Pascal (if would even give us some of the features you want: string
and array bounds checking) though C might be more efficient because
it's closer to the metal.

> So what I've been tinkering with, is not a new language, but a
> C dialect enhanced to make kernel programming simpler.

That's my point: another nonstandard dialect of C, no matter how
useful, will only alienate new people from joining the project. A
subset of C++ will not.

>an option to check all function pointers for
> non-null-ness before jumping through them.

At compile time or at runtime? :) At compile time it's practically
impossible in C, at runtime, the only thing you could reasonably do is
panic, which doesn't gain you anything...

I'd rather go for some kind of transparent debugging infrastructure
(even if it means patches to the compiler), like malloc debuggers in
userland or garbage collectors, which keep the language pretty much
intact and standard.

These are just my opinions, I haven't designed any OSes lately :)