Date: Tue, 30 Oct 2007 07:03:30 +0000 From: "Poul-Henning Kamp" <phk@phk.freebsd.dk> To: "Ivan Voras" <ivoras@freebsd.org> Cc: freebsd-arch@freebsd.org Subject: Re: C++ in the kernel Message-ID: <35772.1193727810@critter.freebsd.dk> In-Reply-To: Your message of "Tue, 30 Oct 2007 00:00:45 %2B0100." <9bbcef730710291600w607e46d8x8c893aa4e53b597d@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <9bbcef730710291600w607e46d8x8c893aa4e53b597d@mail.gmail.com>, "Ivan
Voras" writes:
>On 29/10/2007, Poul-Henning Kamp <phk@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@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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?35772.1193727810>