From owner-freebsd-arch@FreeBSD.ORG Tue Oct 30 10:46:10 2007 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B522316A420 for ; Tue, 30 Oct 2007 10:46:10 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail12.syd.optusnet.com.au (mail12.syd.optusnet.com.au [211.29.132.193]) by mx1.freebsd.org (Postfix) with ESMTP id D6E6D13C4B2 for ; Tue, 30 Oct 2007 10:46:09 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from server.vk2pj.dyndns.org (c220-239-20-82.belrs4.nsw.optusnet.com.au [220.239.20.82]) by mail12.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id l9UAjtDK006371 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Oct 2007 21:45:56 +1100 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.1/8.14.1) with ESMTP id l9UAjt43057638; Tue, 30 Oct 2007 21:45:55 +1100 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.1/8.14.1/Submit) id l9UAjs4x057637; Tue, 30 Oct 2007 21:45:54 +1100 (EST) (envelope-from peter) Date: Tue, 30 Oct 2007 21:45:54 +1100 From: Peter Jeremy To: Ivan Voras Message-ID: <20071030104554.GZ70883@server.vk2pj.dyndns.org> References: <33676.1193689342@critter.freebsd.dk> <9bbcef730710291600w607e46d8x8c893aa4e53b597d@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="zBPbvmIlJjvpbu6L" Content-Disposition: inline In-Reply-To: <9bbcef730710291600w607e46d8x8c893aa4e53b597d@mail.gmail.com> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.16 (2007-06-09) Cc: Poul-Henning Kamp , freebsd-arch@freebsd.org Subject: Re: C++ in the kernel X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2007 10:46:10 -0000 --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--