Re: C++ intermediate representation.

Chris F Clark <>
16 May 2005 00:59:38 -0400

          From comp.compilers

Related articles
[9 earlier articles]
Re: C++ intermediate representation. (Gabriel Dos Reis) (2005-05-15)
Re: C++ intermediate representation. (2005-05-15)
Re: C++ intermediate representation. (2005-05-15)
Re: C++ intermediate representation. (2005-05-15)
Re: C++ intermediate representation. (2005-05-15)
Re: C++ intermediate representation. (bjarne) (2005-05-15)
Re: C++ intermediate representation. (Chris F Clark) (2005-05-16)
Re: C++ intermediate representation. (Ira Baxter) (2005-05-21)
| List of all articles for this month |

From: Chris F Clark <>
Newsgroups: comp.compilers
Date: 16 May 2005 00:59:38 -0400
Organization: The World Public Access UNIX, Brookline, MA
References: 05-05-023 05-05-068 05-05-077 05-05-087 05-05-103 05-05-111 05-05-123
Keywords: C++, history
Posted-Date: 16 May 2005 00:59:38 EDT

First, off let me apologize a little. I can get carried away in my
opinions sometimes. A lot of respect must be extended to someone who
builds anything that works in practice, and C++ does quite a bit
better than that. I know that I will ever create anything that will
have the impact C++ has had.

In that light, the flaws in C++ should be considered minor. The
constructor syntax is just a personal peeve of mine, because it leads
one in a particular direction, and if one had stayed with the C
initializer syntax, other choices would have gone a different
direction also.

Bjarne Stroustrup wrote:

> 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.

This explanation makes perfect sense. The fact that C itself is hard
to parse, could easily have lead to simplifying assumptions at the
start of C++ design, such that the conflicts I would have expected to
see would have been pre-resolved. And, I certainly wouldn't argue
that redundant parenthesis are necessarily a good feature of C's
declaration syntax.

At some level, I think that means we shouldn't generally design
languages that use all the parsing power we have. That was one of the
strengths of Pascal; one could parse it with a simple LL(1) parser,
aside from one little issue with "..". That also made Pascal programs
simple to understand, since they weren't (syntactically) ambiguous.

We had some of the same issues with Yacc++. We wanted yacc
compatibility. However, the optional semicolons at the end of rules
make the language tougher to parse (and make error recovery harder).
If you disallow optional semicolons, yacc grammars are also LL(1).
Now, although we could parse LR(2) grammars, as allowing optional
semicolons would have made it, it seemed like a pointless extension,
as it does not make grammars more readable. Keeping the grammar LL(1)
seemed worthwhile. I try to maintain that LL(1) property as I add new
features to Yacc++. I'm pretty sure our current grammar is nearly
LL(1). The only thing which keeps it from being completely LL(1) is
that we don't use "reserved" words--that is keywords can also be used
as identifiers. (Even with the non-reserved word feature, the grammar
is still LALR(1) (and LL(2) I believe).)


Chris Clark Internet :
Compiler Resources, Inc. Web Site :
23 Bailey Rd voice : (508) 435-5016
Berlin, MA 01503 USA fax : (978) 838-0263 (24 hours)

Post a followup to this message

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