Re: Is C++ really used ? (Daniel J. Salomon)
4 May 1997 00:20:45 -0400

          From comp.compilers

Related articles
Is C++ really used ? (1997-04-22)
Re: Is C++ really used ? (David Chase) (1997-04-22)
Re: Is C++ really used ? (Kevin Jacobs) (1997-04-30)
Re: Is C++ really used ? (1997-05-04)
Re: Is C++ really used ? (Kim Knuttila) (1997-05-04)
Re: Is C++ really used ? (John Lilley) (1997-05-04)
Re: Is C++ really used ? (1997-05-04)
Re: Is C++ really used ? (Christopher Glaeser) (1997-05-04)
Is C++ really used ? (Peter Brueckner) (1997-05-04)
Re: Is C++ really used ? danwang@nordica.CS.Princeton.EDU (1997-05-07)
[12 later articles]
| List of all articles for this month |

From: (Daniel J. Salomon)
Newsgroups: comp.compilers
Date: 4 May 1997 00:20:45 -0400
Organization: Computer Science, University of Manitoba, Winnipeg, Canada
References: 97-04-156
Keywords: C, C++, OOP

Paulo Jose Pinto - LEI <> 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

Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.