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

"Aaron Gray" <ang.usenet@gmail.com>
27 Apr 2007 11:31:32 -0400

          From comp.compilers

Related articles
parsing ISO C++(1998/2003) parthaspanda2005@yahoo.com (2007-04-14)
Re: parsing ISO C++(1998/2003) ang.usenet@gmail.com (Aaron Gray) (2007-04-18)
Re: parsing ISO C++(1998/2003) parthaspanda2005@yahoo.com (2007-04-19)
Re: parsing ISO C++(1998/2003) ang.usenet@gmail.com (Aaron Gray) (2007-04-23)
Re: parsing ISO C++(1998/2003) haberg@math.su.se (2007-04-23)
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: "Aaron Gray" <ang.usenet@gmail.com>
Newsgroups: comp.compilers
Date: 27 Apr 2007 11:31:32 -0400
Organization: Compilers Central
References: 07-04-052 07-04-059 07-04-107
Keywords: C++, parse
Posted-Date: 27 Apr 2007 11:31:32 EDT

"Ira Baxter" <idbaxter@semdesigns.com> wrote in message
> "Aaron Gray" <ang.usenet@gmail.com> wrote in message
>> <parthaspanda2005@yahoo.com> wrote in message
>> > No matter how many shots at it, I havent been
>> > able to get bison/yacc to parse the C++ grammar
>> > specified in the reference manual.
>>
>> GLR (Bison has GLR) was ment to be the answer, although it is slow
>> compared
>> to other techniques.
>>
>> Elkhound and Elsa tried GLR approach and failed.
>
> Failed? From what I hear, Elsa can parse virtually all of ANSI C++.
> What's the failure, exactly?


Okay from the Elsa web page it looks a lot better now than it did a
six months ago, I'll say that


I would be interested in how well it would parse Boost "libraries".


>> 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 code. It uses
> GLR to parse variety of C++ dialects (ANSI, GNU,
> MS including 2005), with grammar rules taken pretty directly from
> from ANSI standard (and adjusted according to dialects, etc.).
> See http://www.semanticdesigns.com/Products/FrontEndsd/CppFrontEnds.html


This is indeed encouraging.


>> > How do I get the grammar in the manual
>> > not to change much as well as pass under
>> > bison/yacc?
>>
>> Thats probably impossible.
>>
>> Aaron
>
> Use GLR. There are several proof by examples.


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


> So this is very practical.
>
> However, you'll find that there is an enormous amount of work to build
> a working C++ front end above and beyond parsing.
>
> If you think of parsing C++ as climbing foothills, getting the rest of
> the front end right (preprocessor, name and type resolution, managing
> the real dialects used, linking) is like climbing the Himalayas.
> People don't seem to understand this very well. Maybe it because they
> never get past parsing.


Yes I am well aware from looking at GCC source code.


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


Aaron



Post a followup to this message

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