This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: A FrontEnd in C++?

On Wed, 21 Aug 2002, Michael Matz wrote:

> Hi,
> 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
> burden.
> Ciao,
> Michael.
> 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 
std::set<tree>, etc.
It seems trivial, but it's really a lot nicer to work with classes.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]