Comparing Mature C++ Parsers (Alexy Khrabrov)
13 May 1996 14:28:05 -0400

          From comp.compilers

Related articles
Comparing Mature C++ Parsers (1996-05-13)
Re: Comparing Mature C++ Parsers (1996-05-19)
| List of all articles for this month |

From: (Alexy Khrabrov)
Newsgroups: comp.compilers
Date: 13 May 1996 14:28:05 -0400
Organization: Computer Command and Control Corporation
Keywords: C++, parse, question

Dear authors of the Mature C++ Parsers,

I am going to reuse an existing C++ parser in a software understanding
environment. So far, I considered CMU C++ parser, Brown University
Cppp, Rational's C2Ada, and PCCTS. (If you know of other parsers,
about as mature, as yours, please let me know and I will forward these
questions to their authors, too.) The questions which I have may be
of interest to other users of these systems, so I'd appreciate their
authors' and experienced users' summarizing how these systems classify
according to the following questions, Q:

1. Identification or Comprehension?

Does your system create internal representation? Is it easier for
compiler-related use, than the source, and how?

1.1. Q: What type of internal representation, IR, is used in your C++
parser? Is there a full walkable (tree) representation of the source
at some (final) point in parsing?

1.2. Q: What is the type of the internal tree nodes? Are all the
nodes fully defined? To what final form are all the ambiguities
in/between the nodes resolved and how?

1.3. Q: How the symbol tables are maintained, if present?

2. Means of External Coordination

Let's call "Import Table," IT, a construct which represents all of the
external entities used by a unit. In C++, we always know, if such an
import is requested (by the absence of the local definition). The
usage, encapsulated in the Import table, is a necessity and actually
happens. (In C++, the actual exporter may be not fully known until
the linkage-time, though.)

Let's call "Export Table," ET, a construct which knows about all the
entities in the current unit, which can potentially be used outside of
it. For a reusable/stand-alone unit, this is an optional export. In
a system, partial or complete, it would be useful to record, which
external units actually use the current one. These actual usages may
or may not be recorded in the ET.

2.1 Q: How Import and Export tables are represented in your parser?
Can these two tables be easily extracted from your IR? Do you record
the export relation for the Exporter ("used by" list)?

3. Scalability and Database of the Parses

3.1. What is the compilation unit of the parse -- file? Compilation
as a group of files? How the separate parses of the separate, but
related compilation units of a system are coordinated, using their
Means of External Coordination (above)?

3.2. How is the IR stored between the parses of the related
components of a system? Is there a convenient technique for long-term
storage of the parsing results -- IRs, STs? E.g., as Object-Oriented
Databases on disk?

Summary: S.1. Q: How much of a compiler's job does your system do?
Mostly answered by (1) -- any further parallels?

S.2. Q: How much of a linker's job does your system do? Mostly
answered by (2) -- any further parallels?

Alexy V. Khrabrov <,>

Post a followup to this message

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