C++ in the kernel

[Ivan Voras]

On 30/10/2007, Peter Jeremy <peterjeremy at optushome.com.au> wrote:
> On Tue, Oct 30, 2007 at 12:00:45AM +0100, Ivan Voras wrote:
> >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.
>
> Pascal was designed for teaching programming.  I don't think it should
> be used in any production environment.  Some of the design decisions
> (eg no logical short-cutting) make writing real code quite painful.
> PrimeOS was written in FORTRAN - which I think was stretching the
> language rather a lot.  Multics was written in PL/I.  The Modula
> family were designed for systems programming.

Of course I'm not suggesting to rewrite the kernel in Pascal (or anything else).

> >> 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.
>
> It depends on what Poul-Henning intends by "dialect".  I would also
> be concerned about changing the language by adding new keywords or
> magic functions that were required to be understood for the code
> to function correctly.  OTOH, extending (eg) the __attribute__
> syntax to provide optional guidance to the compiler to let it
> produce better code and provide better warnings is a good thing -
> the code is correct with or without the __attribute__ but the
> compiler has a better idea of what the programmer intended.

I think the more advanced examples here: http://wiki.freebsd.org/K are
sufficiently diverged from C to make them ugly :)

> >(even if it means patches to the compiler),
>
> I see no reason not to patch the compiler if we can make it generate
> code and/or warnings that make it easier to locate and/or avoid bugs.

I think the context of my quote was in favour of this, as long as the
language remains standard.

On the other hand, if the goal is to make debugging easier, isn't
DTrace going to be "The Way" to do it?