This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Quality of the g++ front-end
- To: johnw at emacs dot org
- Subject: Re: Quality of the g++ front-end
- From: "Martin v. Loewis" <martin at loewis dot home dot cs dot tu-berlin dot de>
- Date: Wed, 9 Feb 2000 01:35:32 +0100
- CC: gcc at gcc dot gnu dot org
- References: <20000208204421.7997.qmail@emacs.org>
> My question is: What is your estimation of the qulity of the g++
> front-end?
As one of the participants, I'm probably biased, but since you've
asked:
There are three different ways to interpret your question:
- from a point of standards compliance, I think g++ is a very good
compiler, at least compared to a number of other products in use.
- from the point of code quality, there is still a lot to be desired;
a number of common optimizations are not (yet) performed.
- from the viewpoint of exensibility: g++ is quite modular. There
is not only the separation of front-end and back-end; even the
front-end consists of modular pieces
- from the viewpoint of documentation: the source is the documentation,
more or less
- from the viewpoint of testibility: the test suite is great, and
finds most new bugs before users do.
Well, that's four ways.
> How adaptable to syntactic changes is it?
The parser is yacc-based, and it is difficult to extend. If you could
arrange that somebody donates a parser rewrite, that would be much
appreciated; I hope it will happer sooner or later, anyway. There are
certain C++ features which you cannot really do in the current parser
(even though some of these issues are really
nobody-cares-border-cases)
If you are familiar with yacc and its inner workings, it should be
possible to hack any change you want.
> Is this a codebase the maintainers wish could be rewritten sometime
> soon?
The parser? Definitely. There was already work in progress to
separate-out things (into semantics.c), but I'm not certain how much
of a new parser is actually done.
> Would you discourage the idea of extending it to meet our needs?
Since you write from emacs.org, I assume you have no problems with
such extensions becoming free software. If the extensions are clearly
documented (i.e. with a well-defined meaning), and if there is already
a user base for these specific extensions, then I think it would be a
good thing to have them supported in gcc. g++ already has supported
for a number of VC++ features, like DLL-exported classes, or COM
classes.
Adding those property fields (or whatever they are called) might be a
natural thing to do - even though there is a certain style of in gcc
extensions that would be even better (__attribute__). For example,
__declspec(dllimport) is not builtin in gcc; it can be implemented as
a #define expanding to __attribute__((dllimport)).
Regards,
Martin