On May 31, 2010, at 14:25, Mark Mitchell wrote: > That doesn't necessarily mean that we have to use lots of C++ features > everywhere. We can use the C (almost) subset of C++ if we want to in > some places. As an example, if the Fortran folks want to use C in the > Fortran front-end, then -- except to the extent required by the common > interfaces, those files could read as if they were C code. But, I think > they'd still need to be compiled with a C++ compiler because they'll > probably pull in headers that use C++ constructs.
I don't see why the implementation language of the front end should necessarily be tied to that of the back end. One of the benefits we should get from switching implementation language is a cleaner interface between the language-specific parts of the compiler and the shared back end files. For the Ada compiler, we've never found it a disadvantage to use Ada as implementation language, even though the back end is written in C. The hard parts of mapping Ada idioms to the intermediate languages used in the back end have never been related to the language used for implementing the front end or back end. If anything, the strict separation between front end and back end data structures has helped avoiding inadvertent reuse of representations for constructs with similar yet subtly different properties. Ideally, when having a full C++ definition of the back end interface, we can use straight type and function definitions, instead of webs of header files with macro definitions. Maybe, some day, we could even use Ada directly to interface with libbackend, eliminating the last remaining non-Ada code in the Ada front end. However, it seems backwards to decide wether we want to change implementation language before we even have an outline of a design for a new interface, or at least some agreement on design goals. If we do not have a path to rewriting tree.h and friends using C++ to raise the abstraction level and improve maintainability of GCC (while maintaining performance and avoiding overgeneralization and needless complexity), I am not sure the cost of moving to C++ will result in many gains. Once we're using C++, there will be a great temptation to use overly complex data structures that would have been inconceivable with C. The best defense against this is a clear design that, at least for the most significant data structures, specifies the interface that is going to be used. Here is where we decide how we're going to do memory management, where we need dynamic data structures, where we may need dispatching etc. If we're just going to get some new power tools for our workshop and let people have at it, the lessons we'll learn might end up being more about what not to do, rather than a show case of their effective use. In short, what we seem to be missing is a clear objective on what we want to accomplish by switching to C++ and how we'll reach those goals. Without that, switching might be ill considered and not in GCC's best interest in the long run. -Geert
