Date: Tue, 30 Oct 2007 21:45:54 +1100 From: Peter Jeremy <peterjeremy@optushome.com.au> To: Ivan Voras <ivoras@freebsd.org> Cc: Poul-Henning Kamp <phk@phk.freebsd.dk>, freebsd-arch@freebsd.org Subject: Re: C++ in the kernel Message-ID: <20071030104554.GZ70883@server.vk2pj.dyndns.org> In-Reply-To: <9bbcef730710291600w607e46d8x8c893aa4e53b597d@mail.gmail.com> References: <fg4bij$m42$1@ger.gmane.org> <33676.1193689342@critter.freebsd.dk> <9bbcef730710291600w607e46d8x8c893aa4e53b597d@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--zBPbvmIlJjvpbu6L Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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. >> 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. > A subset of C++ will not. I suspect this will alienate C programmers (because it's not C) as well as C++ programmers (because it's missing their favourite feature). >(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. --=20 Peter --zBPbvmIlJjvpbu6L Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFHJwti/opHv/APuIcRAq9IAJwNBFpAn3sJNOhKfU3p9qVSnlpWpgCeIKnV 8ntHvGx3CiK174mj5N52fic= =XVYZ -----END PGP SIGNATURE----- --zBPbvmIlJjvpbu6L--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20071030104554.GZ70883>