Related articles |
---|
[10 earlier articles] |
Re: C++ intermediate representation. mefrill@yandex.ru (2005-05-15) |
Re: C++ intermediate representation. comeau@panix.com (2005-05-15) |
Re: C++ intermediate representation. comeau@panix.com (2005-05-15) |
Re: C++ intermediate representation. comeau@panix.com (2005-05-15) |
Re: C++ intermediate representation. bjarne@gmail.com (bjarne) (2005-05-15) |
Re: C++ intermediate representation. cfc@shell01.TheWorld.com (Chris F Clark) (2005-05-16) |
Re: C++ intermediate representation. idbaxter@semdesigns.com (Ira Baxter) (2005-05-21) |
From: | "Ira Baxter" <idbaxter@semdesigns.com> |
Newsgroups: | comp.compilers |
Date: | 21 May 2005 00:00:53 -0400 |
Organization: | http://extra.newsguy.com |
References: | 05-05-023 05-05-068 05-05-077 |
Keywords: | C++, parse |
Posted-Date: | 21 May 2005 00:00:53 EDT |
"Chris F Clark" <cfc@shell01.TheWorld.com> wrote in message
> > Parsing C++ properly is no mean feat. C++'s grammar is ambiguous, as
> > well as the basic type/identifier ambiguity C has, C++ has its own
> > ambiguities.
> First, there is no grammar that one can parse with a backtracking
> recursive descent parser that cannot be parsed with a GLR parser.
I agree with Chris, although we might talk about how long it takes to
parse in cases where there is considerable ambiguity.
However, we seem to be parsing C++ just fine, ambiguities and all,
with our GLR parser (built into the DMS Software Reengineering
Toolkit). And it matches the one in the reference manually pretty
closely.
I can attest personally to the convenience of being able to write
context free rules that *just work*.
--
Ira D. Baxter, Ph.D., CTO 512-250-1018
Semantic Designs, Inc. www.semdesigns.com
Return to the
comp.compilers page.
Search the
comp.compilers archives again.