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: [RFC] Switching implementation language to C++

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.


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