Re: Reusing free parsers for modern C++

"Ira D. Baxter" <>
24 May 2000 01:50:10 -0400

          From comp.compilers

Related articles
Reusing free parsers for modern C++ (Brian Smith) (2000-05-08)
Re: Reusing free parsers for modern C++ (Bruce Stephens) (2000-05-10)
Re: Reusing free parsers for modern C++ (Mark Brown) (2000-05-12)
Re: Reusing free parsers for modern C++ (2000-05-15)
Re: Reusing free parsers for modern C++ (Robert Sherry) (2000-05-22)
Re: Reusing free parsers for modern C++ (Ira D. Baxter) (2000-05-24)
| List of all articles for this month |

From: "Ira D. Baxter" <>
Newsgroups: comp.compilers
Date: 24 May 2000 01:50:10 -0400
Organization: Posted via Supernews,
References: 00-05-034 00-05-088
Keywords: parse

Semantic Designs offers the DMS Reengineering Toolkit,, with a robust
C/C++ front end parser that handles preprocessor directives,
automatically builds an AST retaining comments, literal formats,
etc. can prettyprint the AST back to source form reproducing the
comments/ literals, and can carry out pattern-directed transformations
on the tree. (DMS also handles many other languages.)

We too had a tough time with the preprocessor directives, involving
which macros are live after a conditional, because of our decision to
process "both sides". After all, the source program is what the
programmer sees, not what the compiler sees. We essentially solve by
a special purpose flow analzyer for macro reaching definitions.

Ira Baxter, Ph.D., CTO 512-250-1018x140
Semantic Designs, Inc., FAX 512-250-1191
12636 Research Blvd #C214, Austin, Texas 78759

> Brian Smith wrote:
> >
> > I am looking for comments and suggestions from people that have used
> > the C++ front end of GCC or any other C++ parser for source code
> > analysis. ...
Robert Sherry <> wrote in message
> I while back I was involved with the Y2K problem. ...
> I developed a tool which eliminated most of these false hits
> ... by looking at the type of the
> variable. This tool was based upon ... PCCTS

> I had a problem with the preprocessor. For statements like:
> #ifdef DEBUG
> int flag = 1;
> #else
> int flag = 0;
> #endif
> I needed to process both sides of the #ifdef. As a result the parser
> would come up the variable flag being multiply defined.
....Perhaps my idea of processing both sides of the #ifdef is
> wrong,

Post a followup to this message

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