Date: Tue, 30 Oct 2007 16:13:45 +0100 From: Maciej Sobczak <prog@msobczak.com> To: freebsd-arch@FreeBSD.org Subject: Re: C++ in the kernel Message-ID: <47274A29.9040801@msobczak.com> In-Reply-To: <20071030055840.GS33488@elvis.mu.org> References: <23408.1193557610@critter.freebsd.dk> <p06240801c34bf1e24986@[128.113.24.47]> <20071030055840.GS33488@elvis.mu.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 successfully reused. Don't reinvent! And don't disperse your energy on exploring anything exotic like Yet Another Language That Nobody Heard About (tm). This is doomed. Regards, -- Maciej Sobczak * www.msobczak.com * www.inspirel.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?47274A29.9040801>