Quality of the g++ front-end

[Martin v. Loewis]

> 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