This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: C/C++ front-end extension a la SWIG?
> any particular recommendations?
I know one of them was announced to comp.lang.c++.moderated or
comp.std.c++ not too long ago - but I forgot the details.
> btw, is the undesirability of the gcc C++ parser related to its
> implementation or to its interface (or both)? if the implementation is
> bad but the interface is ok, perhaps over time the code will change so
> that both are ok.
Depends on where you put the interface. The part that leads up to tree
generation is excellent - it has been proven that the same interface
can be used for multiple programming languages, and that from that
interface, middle-end and back-end can generate to many target chips.
If you put the interface before tree generation (i.e. in the set of
functions called and used by the parser proper), then this is likely
to change when the parser is replaced.
So if you want to take the g++ front-end as a whole, then I would
agree with Mark - that might be certainly useful, and could get well
the same position as the EDG front-end.
Rethinking it, a parser only (i.e. a syntax analyser) for C++ cannot
work at all. You always need semantical analysis to find out what the
type names are, or you couldn't tell apart cases like
a*b;
c<d,e>f;
Readers familiar with C++ but not too familiar with C++ parsing are
encouraged to find two completions of this program, so that each line
means something completely different in each program :-)
That, in turn, means that you need a significant part of the g++ front
end - in fact, there isn't much you could leave out.
Regards,
Martin