Re: C++ intermediate representation.

"bjarne" <bjarne@gmail.com>
15 May 2005 16:14:01 -0400

          From comp.compilers

Related articles
[8 earlier articles]
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)
Re: C++ intermediate representation. idbaxter@semdesigns.com (Ira Baxter) (2005-05-21)
| List of all articles for this month |

From: "bjarne" <bjarne@gmail.com>
Newsgroups: comp.compilers
Date: 15 May 2005 16:14:01 -0400
Organization: http://groups.google.com
References: 05-05-02305-05-068 05-05-077 05-05-087 05-05-103 05-05-111
Keywords: C++, history, design
Posted-Date: 15 May 2005 16:14:01 EDT

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.


Gabriel Dos Reis wrote:
> 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.


Correct. The int(a); problem was indeed known and considered
unsolvable by experts (not just me) at the time. Consequently, early
C++ designs deemed redundant parentheses (as in int(a);) illegal, thus
avoiding the declaration/cast ambiguity. Later, the LALR(1) C grammar
appeared and I had to back off in the interest on C compatibility. I
suspect that choosing C compatibility in this case was the wrong
decision, but it seemed inevitable at the time.


  -- Bjarne Stroustrup; http://www.research.att.com/~bs


Post a followup to this message

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