This is the mail archive of the
mailing list for the GCC project.
Re: A FrontEnd in C++?
- From: Michael Matz <matz at suse dot de>
- To: Daniel Berlin <dberlin at dberlin dot org>
- Cc: Zack Weinberg <zack at codesourcery dot com>, <gcc at gcc dot gnu dot org>
- Date: Wed, 21 Aug 2002 20:34:58 +0200 (CEST)
- Subject: Re: A FrontEnd in C++?
On Wed, 21 Aug 2002, Daniel Berlin wrote:
> > No. The intrinsic complexity burden I am talking about is exclusively
> > a function of the number of different languages used in the source
> > tree (ignoring runtime libraries). It doesn't matter which bits are
> > written in which languages.
> Then, in the case of a frontend written in C++, the complexity burden
> would not increase, since libstdc++ and libsupc++ are already written in
> C++ (as are parts of libjava, etc).
Note, how Zack cleverly ruled out runtime libraries ;-)
I agree, that more languages mean more complexity, of course. But IMHO
C++ is just so much more better suited for dealing with data structures,
that this feature nullifies the burden. OTOH this all remains
theoretical, as long as there's no actual frontend written in C++ (or
whatever else). If it pops up, we can value if it really adds too much
P.S.: I even thought sometimes about (re)writing some of the optimizations
in C++. So the stage1 compiler simply would miss some optimizations (as
it still would be translated with just the C compiler), and we would need
a four stage bootstrap. But as most of the base data structures in the
backend would be needed to remain C, the value of this might be