Re: parsing ISO C++(1998/2003)

"Ira Baxter" <idbaxter@semdesigns.com>
28 Apr 2007 23:30:02 -0400

          From comp.compilers

Related articles
[5 earlier articles]
Re: parsing ISO C++(1998/2003) idbaxter@semdesigns.com (Ira Baxter) (2007-04-26)
Re: parsing ISO C++(1998/2003) torbenm@app-7.diku.dk (2007-04-26)
Re: parsing ISO C++(1998/2003) ang.usenet@gmail.com (Aaron Gray) (2007-04-27)
Re: parsing ISO C++(1998/2003) ang.usenet@gmail.com (Aaron Gray) (2007-04-27)
Re: parsing ISO C++(1998/2003) idbaxter@semdesigns.com (Ira Baxter) (2007-04-28)
Re: parsing ISO C++(1998/2003) idbaxter@semdesigns.com (Ira Baxter) (2007-04-28)
Re: parsing ISO C++(1998/2003) idbaxter@semdesigns.com (Ira Baxter) (2007-04-28)
| List of all articles for this month |

From: "Ira Baxter" <idbaxter@semdesigns.com>
Newsgroups: comp.compilers
Date: 28 Apr 2007 23:30:02 -0400
Organization: NewsGuy - Unlimited Usenet $19.95
References: 07-04-052 07-04-059 07-04-107 07-04-132
Keywords: parse, C++
Posted-Date: 28 Apr 2007 23:30:02 EDT

"Aaron Gray" <ang.usenet@gmail.com> wrote
> "Ira Baxter" <idbaxter@semdesigns.com> wrote in message
>
> >> All the major C++ parsers are hand coded, recursive decent and precedance
> >> based binary ops.
> >
> > Guess our DMS Software Reengineering Toolkit isn't a major C++ parser.
> > Nonetheless, it is NOT hand coded. It uses
> > GLR to parse variety of C++ dialects


> I am aware of Elsa, but no other open C++ GLR parsers.


Dunno what you mean by "open" If you mean "free source",
I agree, there aren't any others I know about. If you
mean "available source code", ours is commercially available.


> The only other issue brought up was about parsing and disambiguation
> time of GLR as compared to combined recursive decent and operator
> preceedance parsing.


It is true that our GLR parsers are not as fast as hand-coded
recursive descent parsers.


That's because we aren't trying to compete with compiler front ends.
On the other hand, typical compiler front ends don't capture comments
and formats of literals, can't transform the resulting trees as C++
trees, and can't reproduce C++ source code (I think EDG actually can
do this) that is still compilable. We are optimizing for different
goals. Speed wasn't at the top of our list.


--
Ira Baxter, CTO
www.semanticdesigns.com


Post a followup to this message

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