This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Bridging the new C/C++ grok....() impedance mismatch
On Tue, 6 Jul 2004, Ziemowit Laski wrote:
> Hmm, that's tempting... by "merge the C and C++ front-ends", hopefully
> you mean "tweak the C++ front-end to also accept C"? Most of that work
> should be fairly trivial, me thinks; the tricky part will be in
> handling areas where C++ and C99 differ.
Don't fall into the trap of thinking that most of the differences, even
from C90, are documented in ISO 14882 Annex D. You won't find there
mention that
typedef void v;
void f(v){}
is valid C (as confirmed in C90 DR#157) and invalid C++ (as confirmed in
closed C++ core issue 18), as just one example of many. C++ and C are
different languages, albeit with much commonality, and given that they
have been diverging since well before C89 just because both deal with a
subject doesn't mean they deal with it the same way. Also don't fall into
the trap of thinking there are two languages involved; there are at least
seven (three C and one C++ standards, plus GNU extended versions of C90,
C99 and C++; *none* of the standards are yet completely implemented in
GCC). The GNU C extensions are probably as much a problem as standard
differences (I hope you don't want to add nested functions to the GNU C++
language ...). Plus all the warnings only implemented for C (e.g. almost
all of -Wparentheses) - though implementing those for C++ is a good idea
regardless. Essentially every line of code not immediately obviously just
dealing with C++-specific features would need comparison with the text of
C90 and C99 (you're very familiar with the texts of the language parts of
C90, C90-AMD1, C90-TC1, C90-TC2, C99, C99-TC1 and C++03, and all DRs
thereto, right?) and the existing properties of GNU C to ascertain whether
a conditional is needed (and if so, how local the conditional should be -
some aspects of the languages have simple local differences, while some
aspects such as declaration handling and name lookup have essentially no
resemblence between the standards at all), while avoiding any compile-time
performance or conformance regressions for either language.
You could start by getting the GNU C extensions documentation (including
those extensions not currently documented) up to the ISO standard level
and ensuring we have testcases covering them, and all GNU C warnings,
properly, so there's some well-defined notion of what "gcc" is actually
meant to do when compiling C. That's something that can be done
incrementally (always to be preferred if possible over any sort of
monolithic large project) and of which any part is useful.
--
Joseph S. Myers http://www.srcf.ucam.org/~jsm28/gcc/
jsm@polyomino.org.uk (personal mail)
jsm28@gcc.gnu.org (Bugzilla assignments and CCs)