Related articles |
---|
Infinite look ahead required by C++? ng2010@att.invalid (ng2010) (2010-02-05) |
Re: Infinite look ahead required by C++? cfc@shell01.TheWorld.com (Chris F Clark) (2010-02-06) |
Re: Infinite look ahead required by C++? idbaxter@semdesigns.com (Ira Baxter) (2010-02-06) |
Re: Infinite look ahead required by C++? thurston@complang.org (Adrian Thurston) (2010-02-08) |
Re: Infinite look ahead required by C++? sh006d3592@blueyonder.co.uk (Stephen Horne) (2010-02-09) |
Re: Infinite look ahead required by C++? gah@ugcs.caltech.edu (glen herrmannsfeldt) (2010-02-10) |
Re: Infinite look ahead required by C++? sh006d3592@blueyonder.co.uk (Stephen Horne) (2010-02-10) |
Re: Infinite look ahead required by C++? cfc@shell01.TheWorld.com (Chris F Clark) (2010-02-10) |
[9 later articles] |
From: | Chris F Clark <cfc@shell01.TheWorld.com> |
Newsgroups: | comp.compilers |
Date: | Sat, 06 Feb 2010 13:22:52 -0500 |
Organization: | The World Public Access UNIX, Brookline, MA |
References: | 10-02-024 |
Keywords: | C++, parse |
Posted-Date: | 10 Feb 2010 10:59:21 EST |
"ng2010" <ng2010@att.invalid> writes:
> What elements of C++ make it so hard to parse? Is it a weakness of
> compiler designs rather than a weakness of the language design? I've read
> somewhere that the language requires potentially infinite look ahead.
> Why? And how do compilers handle it?
> [It's ambiguous syntax. Others can doubtless fill in the details. -John]
The main ambiguity problem is very simple. Declarations and
expressions can look the same, and if the text can be an expression it
is, otherwise it is a declaration. Inside an expression and a
declaration, things are not always broken into the same fragments
(non-terminals), so you need to know which you are parsing to know how
to divide the text up. However, you may need to parse arbitrarily far
ahead to get to the text which is legal only if it is treated as a
declaration (or only legal in an expression) to disambiguate.
In the following example, I build up the issue slowly, notice how the
last two differ.
typedef class c *p;
class d {
p x; // decl
p(y); // decl
p(f(p(x))); // prototype
p(z(p(x))) { // defn
p(z(p(x))); // expression
p(f(p(q))); // prototype
return 0;
};
};
Hope this helps,
-Chris
******************************************************************************
Chris Clark email: christopher.f.clark@compiler-resources.com
Compiler Resources, Inc. Web Site: http://world.std.com/~compres
23 Bailey Rd voice: (508) 435-5016
Berlin, MA 01503 USA twitter: @intel_chris
------------------------------------------------------------------------------
Return to the
comp.compilers page.
Search the
comp.compilers archives again.