Re: C++ intermediate representation.

Gabriel Dos Reis <gdr@integrable-solutions.net>
15 May 2005 14:31:11 -0400

          From comp.compilers

Related articles
[3 earlier articles]
Re: C++ intermediate representation. henry@spsystems.net (2005-05-14)
Re: C++ intermediate representation. angray@beeb.net (Aaron Gray) (2005-05-14)
Re: C++ intermediate representation. ralphpboland@yahoo.com (Ralph Boland) (2005-05-14)
Re: C++ intermediate representation. cfc@shell01.TheWorld.com (Chris F Clark) (2005-05-14)
Re: C++ intermediate representation. gsc@zip.com.au (Sean Case) (2005-05-14)
Re: C++ intermediate representation. robert.hundt@gmail.com (Robert H) (2005-05-15)
Re: C++ intermediate representation. gdr@integrable-solutions.net (Gabriel Dos Reis) (2005-05-15)
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)
[1 later articles]
| List of all articles for this month |

From: Gabriel Dos Reis <gdr@integrable-solutions.net>
Newsgroups: comp.compilers
Date: 15 May 2005 14:31:11 -0400
Organization: Integrable Solutions
References: 05-05-023 05-05-068 05-05-077 05-05-087 05-05-103
Keywords: C++, design

Chris F Clark <cfc@shell01.TheWorld.com> writes:


[...]


| The one thing that surprises me, given Stroustrup's statement about
| building C++ with a yacc parser is how he made some of the design
| mistakes he did. The syntax that uses parenthesis for passing
| constructor arguments in a declaration, so that one cannot easily
| distinguish a declaration of a variable that has constructor arguments
| from a function prototype declaration is an example. That should have
| caused his tool to give him conflicts, indicating that he was
| wandering into an ambiguous grammar and should have found a different
| syntax. Problems like this are why I try to steer people away from
| hand-written recursive descent--one can easily write a parser that has
| inconsistent rules by hand, expecially when one is prototyping and
| adding extensions. The fact that Stroustrup was able to make the same
| mistakes with a tool worries me extremely.


My understanding is that at the time he introduced the
"functional-cast" syntax, all C compilers in production use were
broken in that respect -- meaning, they were unable to parse things
like "int(a)", since Johnson's PCC compiler. Therefore, I believe he
thought that the C definition would eventually be "aligned" to match
practice, e.g. "int(a)" would not be considered a declaration.
Consequently, he made it an expression. "Unfortunately", a few months
later, someone presented a parser capable of parsing "int(a)" as
originally described in K&R. And the C definition never changed in
that respect. Hence the conflict.


As a matter of fact, it is not that he was unaware of the issue (I've
heard that he started "breaking" any C parser in existence at the time
before properly embarking on C with Classes), it was a kind of
"antipicatory" decision. I believe D&E has some paragraphs on that.


--
                                                                                                              Gabriel Dos Reis
                                                                                      gdr@integrable-solutions.net



Post a followup to this message

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