C++ in the kernel
prog at msobczak.com
Tue Oct 30 08:40:28 PDT 2007
Alfred Perlstein wrote:
(I reply also to some previous mail which I didn't get from the list.)
>> That way we don't get caught up in
>> problems when, say, the ABI's for the official C++ language are
>> changed, and we don't want to make major ABI changes in the middle
>> of a STABLE branch.
Do you often change the compiler in the middle of a STABLE branch?
If not, then why are you worried about changes in the language?
They will not magically propagate to the compiler.
Pick the compiler version and stick to it for the whole branch lifetime.
>> It might be prudent to say we're building a new language patterned
>> on something *other* than C++, just to make it clear that we won't
>> be tied to whatever developments coem up in the world of C++.
Why are you worried about developments that can come up?
Do you try to protect yourself from new developments that can come up in
C as well? You don't own neither C++, nor C.
>> I've been meaning to look into D, but I don't have any experience
>> with programming in D, so I don't know if that would work as a
>> basis of a kernel-programming language.
Sorry to say this, but is it worthwhile to look into every single
language which you have no experience with? That might get long.
> I think the right thing to do here is to identify the things we
> need added to C++ and propose those to the standards.
I think you got it completely backwards.
First a bit of context - the C++ standard committee is already in deep
sht^H^H^Hwork to get the current proposals straight and ship the new
standard revision, which is already late. No new proposals are accepted,
unless they save the world.
Considering the usual rythm of standardization process, the next chance
to add anything to C++ will be at the end of the next decade. FreeBSD
might be already dead till that time with Linux overtaking whatever is
left from the community.
You should reverse your thinking and instead ask yourself: what parts
and elements of *current* C++ might be useful for kernel development?
If you identify them you can actually benefit from adapting them.
If not, abandon the idea altogether and continue the current way.
If you try to do anything else, you will only waste resources.
Actually, C++ is being used in embedded and real-time systems as well as
for signal processing, so apparently there *are* some communities that
already gained experience with constrained use of the language.
Presumably some of the constraints that these people face are also valid
in the kernel world, and presumably some of the solutions might be
And don't disperse your energy on exploring anything exotic like Yet
Another Language That Nobody Heard About (tm). This is doomed.
Maciej Sobczak * www.msobczak.com * www.inspirel.com
More information about the freebsd-arch