Related articles |
---|
C++ intermediate representation. shakti.misra@wipro.com (DeltaOne) (2005-05-05) |
Re: C++ intermediate representation. angray@beeb.net (Aaron Gray) (2005-05-13) |
Re: C++ intermediate representation. henry@spsystems.net (2005-05-14) |
Re: C++ intermediate representation. mefrill@yandex.ru (2005-05-15) |
Re: C++ parsing, was intermediate representation. gdr@integrable-solutions.net (Gabriel Dos Reis) (2005-05-15) |
From: | Gabriel Dos Reis <gdr@integrable-solutions.net> |
Newsgroups: | comp.compilers |
Date: | 15 May 2005 17:21:19 -0400 |
Organization: | Integrable Solutions |
References: | 05-05-023 05-05-068 05-05-078 05-05-114 |
Keywords: | C++, parse |
Posted-Date: | 15 May 2005 17:21:19 EDT |
mefrill@yandex.ru (Vladimir) writes:
| henry@spsystems.net (Henry Spencer) wrote in message
| > In his "The Design and Evolution of C++", Stroustrup says that he let
| > Aho and Johnson talk him out of writing his own recursive-descent
| > parser for C++... and he now thinks that was a big mistake.
|
| Stroustrup means using YACC or Bison I think, the programms that
| generate LALR(1) parser and, consequently, demand input grammar must
| be LALR(1). It is known C++ grammar is not LALR(k) for any k. So,
| Stroustrup spent much time trying to write LALR grammar for C++. For
| the moment there is GLR parser as the next generation LALR parsers,
| which makes writing C++ frot-end fast and simple time spending.
In April 2004, I attended the Compiler Construction (part of ETAPS)
conference where a parser for C++ (Elkhound), based on GLR technology,
was presented. My understanding is that, in practice, it was far from
handling C++, notably most uses of templates. I don't know whether
any substantial progress has been made since then.
--
Gabriel Dos Reis
gdr@integrable-solutions.net
Return to the
comp.compilers page.
Search the
comp.compilers archives again.