This is the mail archive of the
mailing list for the GCC project.
Re: A FrontEnd in C++?
- From: Daniel Berlin <dberlin at dberlin dot org>
- To: Michael Matz <matz at suse dot de>
- Cc: Zack Weinberg <zack at codesourcery dot com>, <gcc at gcc dot gnu dot org>
- Date: Wed, 21 Aug 2002 14:50:47 -0400 (EDT)
- Subject: Re: A FrontEnd in C++?
- Reply-to: dberlin at dberlin dot org
On Wed, 21 Aug 2002, Michael Matz wrote:
> 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.
I so agree it's not even funny.
> 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++.
I've actually started doing it many times.
In particular, i've still got the start of an interprocedural middle-end
(IE takes trees from many modules) written in C++.
You can't believe how nice it is to just simply be able to do things like
It seems trivial, but it's really a lot nicer to work with classes.