C++ in the kernel

[Poul-Henning Kamp]

In message <9bbcef730710291600w607e46d8x8c893aa4e53b597d at mail.gmail.com>, "Ivan
 Voras" writes:
>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. 

You don't get my point obviously.  I'm not talking about "being able
to", I'm talking about "being able to improve the quality of".

You're totally right that C++ doesn't help in any way, and that is
exactly my point, I want help from the compiler, not hindrance.

>> 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.

I suspect that C++ might alienate a number of current developers :-)

>>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...

A panic gains you a lot, if it happens before the function pointer
call hoses you, rather than after, when you cannot get a backtrace.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.