Re: New C parser [patch]

["Joseph S. Myers" <jsm@polyomino.org.uk>]

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)