From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8954 invoked by alias); 26 Oct 2004 00:03:43 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 8941 invoked from network); 26 Oct 2004 00:03:41 -0000 Received: from unknown (HELO lon-mail-2.gradwell.net) (193.111.201.126) by sourceware.org with SMTP; 26 Oct 2004 00:03:41 -0000 Received: from digraph.polyomino.org.uk [81.187.227.50] (user: postmaster2815c918op3.polyomino.org.uk) by lon-mail-2.gradwell.net with esmtp (Gradwell gwh-smtpd 1.147) id 417d9455.b330.66; Tue, 26 Oct 2004 01:03:33 +0100 Received: from jsm28 (helo=localhost) by digraph.polyomino.org.uk with local-esmtp (Exim 4.42) id 1CMEoG-0003bL-SS; Tue, 26 Oct 2004 00:03:32 +0000 Date: Tue, 26 Oct 2004 00:37:00 -0000 From: "Joseph S. Myers" X-X-Sender: jsm28@digraph.polyomino.org.uk To: Scott Robert Ladd cc: Ziemowit Laski , gcc-patches@gcc.gnu.org Subject: Re: New C parser [patch] In-Reply-To: <417D8F67.5070105@coyotegulch.com> Message-ID: References: <42A6DEB0-26D4-11D9-9558-000D9330C50E@apple.com> <8354E669-26DE-11D9-B761-000D9330C50E@apple.com> <417D8F67.5070105@coyotegulch.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2004-10/txt/msg02138.txt.bz2 On Mon, 25 Oct 2004, Scott Robert Ladd wrote: > Also, C and C++ are heading down different and incompatible paths. It will be > increasingly difficult to manage the subtle-but-important differences in a > single front end if the two languages continue to diverge. I would add that the calls a few years ago for merging the languages came generally from the C++ side; it has mainly been people with a largely C++ background calling for a merge of the languages, and the same may apply to merging front ends; in both cases the costs fall disproportionately on C. (It has been said that there are three languages, C, C++ and C/C++, the last being that referred to by those who don't understand the difference.) Starting 25 years ago, heading for a single language would have been a better direction. However, we don't get to go back to 25 years ago and change the decisions that were made. We have two languages evolving on diverging tracks; sometimes ideas and features come from one to the other, but because of the different histories may not be quite compatible. Where there are similarities in appearance and a subset of code works in both languages, the underlying concepts in the standards that define what it means in each language may still differ greatly - and there is a clear benefit to each compiler following the relevant underlying concepts directly, rather than just one set of concepts and trying to shoehorn the other on as a set of exceptions to those concepts. There are many other standards layered on the existing C and C++ standards, which do not necessarily get updated for new standard versions, and users with code written and qualified for particular past standard versions, effectively meaning that the multiple C versions need supporting indefinitely (and note C90 is more widely used than C99) and when there is a new C++ version (one with new features as opposed to a defect-fix release such as C++03) there will also be a need for support of multiple C++ versions. Of course code should be shared where appropriate and where it doesn't adversely affect maintenance. For example, the preprocessor concepts are sufficiently nearly identical in the different standards that the preprocessor is usefully shared. I am confident that in future the cp_lexer_* layer will be usable for C as well; the c_lexer_* layer in the new C parser is much simplified from what is there for C++ and is done that way to avoid combining other changes (e.g. lexing up front) not strictly needing to be combined with a new parser, but it is not something that need be different permanently. C only needs 2-token look-ahead unlike the unlimited look-ahead needed for parsing C++, which makes things simpler, but with lexing up front I don't expect the simplicity will actually provide any performance advantages. -- Joseph S. Myers http://www.srcf.ucam.org/~jsm28/gcc/ jsm@polyomino.org.uk (personal mail) joseph@codesourcery.com (CodeSourcery mail) jsm28@gcc.gnu.org (Bugzilla assignments and CCs)