Re: Is C++ really used ? (Shankar Unni)
8 May 1997 21:44:13 -0400

          From comp.compilers

Related articles
[11 earlier articles]
Re: Is C++ really used ? (1997-05-08)
Re: Is C++ really used ? (1997-05-08)
Re: Is C++ really used ? (David Chase) (1997-05-08)
Re: Is C++ really used ? (1997-05-08)
Re: Is C++ really used ? (Cliff Click) (1997-05-08)
Re: Is C++ really used ? nasser@apldbio.COM (Nasser Abbasi) (1997-05-08)
Re: Is C++ really used ? (1997-05-08)
Re: Is C++ really used ? (Bruce Duncan) (1997-05-08)
Re: Is C++ really used ? (1997-05-12)
Re: Is C++ really used ? (Jocelyn Coulmance) (1997-05-12)
Re: Is C++ really used ? (1997-05-13)
| List of all articles for this month |

From: (Shankar Unni)
Newsgroups: comp.compilers
Date: 8 May 1997 21:44:13 -0400
Organization: Chromatic Research, Sunnyvale, CA
References: 97-04-156 97-05-016
Keywords: OOP, design, C++

Daniel J. Salomon ( wrote:

> There were two significant shortcomings in the OOP design of our compiler:

And therein lies the crux of the discussion. Daniel is talking about
an O-O design of a compiler, while the others are talking about
implementing a compiler in C++. Needless to say, the discussion is at

Certainly using C++ as a more advanced C, with better encapsulation
and type checking, is a great idea. I'm all for it, and in fact, have
seen several compilers do this. No argument there.

It's an altogether different thing to design a compiler in an object
oriented fashion from the ground up.

Daniel pointed out the two critical points at which the
straightforward O-O paradigm breaks down: transforming ascii text into
a parse tree, and transforming the tree back into optimized machine

I think the key is that we must recognize that there are three
"processes" involved here, conceptually. The first process parses the
source code and produces a tree of objects.

Once the tree is created, the second "process" performs the entire
frontend semantic analysis, and even generation of a first level of
intermediate code, and can be designed in an object-oriented fashion
("analyze yourself"; "allocate storage for yourself"; "generate
intermediate code for yourself"). You'd need the odd standalone global
objects to manage storage allocation, etc., but overall, the whole
thing can be pretty clean from an O-O point of view.

Once we descend into the third "process" (optimization and code
generation), it's another ballgame once again. Most optimization
algorithms used today are not readily amenable to an object-oriented

However, an object-oriented implementation is not necessary in order
to achieve a modular optimizer design (where passes are
interchangeable and intermixable) - SUIF is a good example of such a
design, as are several commercial optimizers.
Shankar Unni
Chromatic Research (408) 752-9488

Post a followup to this message

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