|Is C++ really used ? firstname.lastname@example.org (1997-04-22)|
|Re: Is C++ really used ? email@example.com (David Chase) (1997-04-22)|
|Re: Is C++ really used ? firstname.lastname@example.org (Kevin Jacobs) (1997-04-30)|
|Re: Is C++ really used ? email@example.com (1997-05-04)|
|Re: Is C++ really used ? firstname.lastname@example.org (Kim Knuttila) (1997-05-04)|
|Re: Is C++ really used ? email@example.com (John Lilley) (1997-05-04)|
|Re: Is C++ really used ? firstname.lastname@example.org (1997-05-04)|
|Re: Is C++ really used ? email@example.com (Christopher Glaeser) (1997-05-04)|
|Is C++ really used ? firstname.lastname@example.org (Peter Brueckner) (1997-05-04)|
|Re: Is C++ really used ? danwang@nordica.CS.Princeton.EDU (1997-05-07)|
|[12 later articles]|
|From:||email@example.com (Daniel J. Salomon)|
|Date:||4 May 1997 00:20:45 -0400|
|Organization:||Computer Science, University of Manitoba, Winnipeg, Canada|
|Keywords:||C, C++, OOP|
Paulo Jose Pinto - LEI <firstname.lastname@example.org> wrote:
|> Is C++ so bad for compilers? After all I'm using it and it seems
|> that everyone else is, so why aren't the books ?
I recently updated my compiler course to use an object-oriented
language, C++, to implement an object-oriented language, Modula-3.
This was the advanced project that gained bonus marks; students still
had the choice of the rusty, old project: implementing Pascal in C.
I found the advanced project to be very educational. There are some
ways that a compiler makes very good use of the OOP paradigm. This
includes things like a symbol table full of pointers to objects of the
base class "symbol" with derived classes for each to of the symbol
categories (types, variables, procedures, etc.) Also the concept of
sending an intermediate form node the message "type check yourself" or
"generate code for yourself" required a rethinking of the traditional
way of traversing the data structure for the intermediate-form. In
general, compiler writing stretched the concepts and capabilities of
OOP and C++ to their limits.
There were two significant shortcomings in the OOP design of our compiler:
1) None of the popular parsing methods such as recursive descent,
LL(1), and LALR(1), map well into an object-oriented design. The
identification of the objects and the messages does not seem
sensible for parsing. In our course we just used Lex++ and Yacc++,
and did not attempt any mapping to OOP principles.
2) In the traditional project, I taught the students to keep the
code-generation functions separate from the parsing functions and
intermediate-form-manipulation functions. That way they could
change compiler back ends easily. In the OOP design this was not
so easy. Since each node of the intermediate form (we used
3-address code) had a method for generating code for itself, the
code generation and intermediate form were closely related. At the
very least, the prototypes for code-generation functions for all
possible architectures would have to be the same. We found even
this weak separation difficult, and it made it hard to take
advantage of target machine idioms.
I would be interested with other people's experience with these two
problems of the OOP design of a compiler.
Daniel J. Salomon -- salomon@cs.UManitoba.CA
Dept. of Computer Science / University of Manitoba
Winnipeg, Manitoba, Canada R3T 2N2 / (204) 474-8687
Return to the
Search the comp.compilers archives again.