blocks|key|356898|text|在Lambda+the+Ultimate上有一个讨论LALR+grammar+for+C%2B%2B的有趣的帖子。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|356899|它包含一个指向PhD+thesis的链接，其中包含对C%2B%2B解析的讨论，说明：|356900|356901|+"C%2B%2B语法是模棱两可的，依赖于上下文，并且可能需要无限的前瞻来解决一些歧义“。|blockquote|356902|356903|356904|它接着给出了一些例子(见pdf的第147页)。|356905|示例如下：|356906|int(x),+y,+*const+z;|code-block|syntax|javascript|356907|含义|356908|int+x;
int+y;
int+*const+z;|356909|请比较：|356910|int(x),+y,+new+int;|356911|356912|(int(x)),+(y),+(new+int));|356913|(逗号分隔的表达式)。|356914|这两个令牌序列具有相同的初始子序列，但不同的解析树依赖于最后一个元素。在消除歧义的标记之前可以有任意多个标记。|356915|entityMap|0|LINK|mutability|MUTABLE|url|http://lambda-the-ultimate.org/|1|http://lambda-the-ultimate.org/node/2158#comment-27800|2|http://www.computing.surrey.ac.uk/research/dsrg/fog/FogThesis.pdf^0|1|J|0|Q|K|1|0|7|A|2|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|1L|8|@]|9|@$A|1M|B|1N|1|1O]|$A|1P|B|1Q|1|1R]]|C|$]]|$1|D|3|E|5|6|7|1S|8|@]|9|@$A|1T|B|1U|1|1V]]|C|$]]|$1|F|3|-4|5|6|7|1W|8|@]|9|@]|C|$]]|$1|G|3|H|5|I|7|1X|8|@]|9|@]|C|$]]|$1|J|3|-4|5|6|7|1Y|8|@]|9|@]|C|$]]|$1|K|3|-4|5|6|7|1Z|8|@]|9|@]|C|$]]|$1|L|3|M|5|6|7|20|8|@]|9|@]|C|$]]|$1|N|3|O|5|6|7|21|8|@]|9|@]|C|$]]|$1|P|3|Q|5|R|7|22|8|@]|9|@]|C|$S|T]]|$1|U|3|V|5|6|7|23|8|@]|9|@]|C|$]]|$1|W|3|X|5|R|7|24|8|@]|9|@]|C|$S|T]]|$1|Y|3|Z|5|6|7|25|8|@]|9|@]|C|$]]|$1|10|3|11|5|R|7|26|8|@]|9|@]|C|$S|T]]|$1|12|3|V|5|6|7|27|8|@]|9|@]|C|$]]|$1|13|3|14|5|R|7|28|8|@]|9|@]|C|$S|T]]|$1|15|3|16|5|6|7|29|8|@]|9|@]|C|$]]|$1|17|3|18|5|6|7|2A|8|@]|9|@]|C|$]]|$1|19|3|-4|5|6|7|2B|8|@]|9|@]|C|$]]]|1A|$1B|$5|1C|1D|1E|C|$1F|1G]]|1H|$5|1C|1D|1E|C|$1F|1I]]|1J|$5|1C|1D|1E|C|$1F|1K]]]]

There is an interesting thread on <a href="http://lambda-the-ultimate.org/" rel="noreferrer">Lambda the Ultimate</a> that discusses the <a href="http://lambda-the-ultimate.org/node/2158#comment-27800" rel="noreferrer">LALR grammar for C++</a>. 

It includes a link to a <a href="http://www.computing.surrey.ac.uk/research/dsrg/fog/FogThesis.pdf" rel="noreferrer">PhD thesis</a> that includes a discussion of C++ parsing, which states that:

<blockquote>
 "C++ grammar is ambiguous,
 context-dependent and potentially
 requires infinite lookahead to resolve
 some ambiguities".
</blockquote>

It goes on to give a number of examples (see page 147 of the pdf).

The example is:

<pre><code>int(x), y, *const z;
</code></pre>

meaning

<pre><code>int x;
int y;
int *const z;
</code></pre>

Compare to:

<pre><code>int(x), y, new int;
</code></pre>

meaning

<pre><code>(int(x)), (y), (new int));
</code></pre>

(a comma-separated expression).

The two token sequences have the same initial subsequence but different parse trees, which depend on the last element. There can be arbitrarily many tokens before the disambiguating one.

blocks|key|359090|text|我认为你已经非常接近答案了。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|359091|LR(1)意味着从左到右的解析只需要一个令牌来超前查看上下文，而LR(∞)意味着无限的超前。也就是说，解析器必须知道即将到来的所有内容，才能找出它现在的位置。|359092|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

I think you are pretty close to the answer. 

LR(1) means that parsing from left to right needs only one token to look-ahead for the context, whereas LR(&infin;) means an infinite look-ahead. That is, the parser would have to know everything that was coming in order to figure out where it is now.

blocks|key|3145868|text|LR解析器在设计上不能处理歧义的语法规则。(在20世纪70年代，当想法被提出时，理论变得更容易了)。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3145869|C和C%2B%2B都允许使用以下语句：|3145870|x+*+y+;|code-block|syntax|javascript|3145871|它有两种不同的解析：|3145872|3145873|它可以是y的声明，作为指向类型x|ordered-list-item|3145874|的指针，它可以是x和y的乘积，丢弃答案。|3145875|3145876|现在，你可能会认为后者是愚蠢的，应该被忽略。大多数人会同意你的观点；然而，在某些情况下，它可能会有副作用(例如，如果multiply是重载的)。但这不是重点。关键是有两个不同的解析，因此一个程序可以有不同的含义，这取决于它应该如何被解析。|3145877|编译器必须在适当的情况下接受适当的一个，并且在没有任何其他信息(例如，关于x的类型的知识)的情况下，必须收集这两个信息，以便决定以后要做什么。因此，语法必须允许这一点。这使得语法含糊不清。|3145878|因此，纯LR解析无法处理此问题。许多其他广泛可用的解析器生成器，例如Antlr、JavaCC、YACC或传统的Bison，甚至是PEG式解析器，也不能以“纯”方式使用。|3145879|有很多更复杂的情况(解析模板语法需要任意的先行，而LALR(k)最多只能提前k个标记)，但只需要一个反例就可以击倒纯LR+(或其他)解析。|3145880|大多数真正的C/C%2B%2B解析器通过使用某种确定性解析器来处理这个示例:它们将解析与符号表集合交织在一起……这样，当遇到"x“时，解析器就知道x是否是一个类型，因此可以在两个可能的解析之间进行选择。但是这样做的解析器不是上下文无关的，LR解析器(纯解析器，等等)(充其量)是上下文无关的。|3145881|人们可以作弊，并在to+LR解析器中添加每个规则的缩减时间语义检查来进行这种消歧。(此代码通常并不简单)。大多数其他解析器类型都有一些方法，可以在解析过程中的不同点添加语义检查，这可以用来实现这一点。|3145882|如果你作弊足够多，你可以让LR解析器在C和C%2B%2B上工作。GCC的人做了一段时间，但放弃了手工编码的解析，我想是因为他们想要更好的错误诊断。|3145883|不过，还有另一种方法：GLR+parsers，它很好、很干净，可以很好地解析C和C%2B%2B，而不需要任何符号表的麻烦。这些是完全上下文无关的解析器(具有有效的无限先行)。GLR解析器简单地接受这两种解析，生成一个“树”(实际上是一个主要类似于树的有向无环图)来表示不明确的解析。解析后传递可以解决多义性。|offset|length|3145884|我们在我们的DMS软件再工程工具包的C和C%2B%2B前端中使用了这项技术(从2017年6月起，这些工具包可以处理MS和GNU语中的完整C%2B%2B17+)。它们已经被用于处理数以百万计的大型C和C%2B%2B系统，通过完整、精确的语法分析生成具有完整源代码细节的AST。(参见the+AST+for+C%2B%2B's+most+vexing+parse.)|3145885|entityMap|0|LINK|mutability|MUTABLE|url|http://en.wikipedia.org/wiki/GLR_parser|1|https://stackoverflow.com/a/17393852/120163^0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|B|B|0|0|3K|10|1|0^^$0|@$1|2|3|4|5|6|7|1L|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|1M|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|1N|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|1O|8|@]|9|@]|A|$]]|$1|K|3|-4|5|6|7|1P|8|@]|9|@]|A|$]]|$1|L|3|M|5|N|7|1Q|8|@]|9|@]|A|$]]|$1|O|3|P|5|N|7|1R|8|@]|9|@]|A|$]]|$1|Q|3|-4|5|6|7|1S|8|@]|9|@]|A|$]]|$1|R|3|S|5|6|7|1T|8|@]|9|@]|A|$]]|$1|T|3|U|5|6|7|1U|8|@]|9|@]|A|$]]|$1|V|3|W|5|6|7|1V|8|@]|9|@]|A|$]]|$1|X|3|Y|5|6|7|1W|8|@]|9|@]|A|$]]|$1|Z|3|10|5|6|7|1X|8|@]|9|@]|A|$]]|$1|11|3|12|5|6|7|1Y|8|@]|9|@]|A|$]]|$1|13|3|14|5|6|7|1Z|8|@]|9|@]|A|$]]|$1|15|3|16|5|6|7|20|8|@]|9|@$17|21|18|22|1|23]]|A|$]]|$1|19|3|1A|5|6|7|24|8|@]|9|@$17|25|18|26|1|27]]|A|$]]|$1|1B|3|-4|5|6|7|28|8|@]|9|@]|A|$]]]|1C|$1D|$5|1E|1F|1G|A|$1H|1I]]|1J|$5|1E|1F|1G|A|$1H|1K]]]]

LR parsers can't handle ambiguous grammar rules, by design. (Made the theory easier back in the 1970s when the ideas were being worked out).

C and C++ both allow the following statement:

<pre><code>x * y ;
</code></pre>

It has two different parses:

<ol>
<li>It can be the declaration of y, as pointer to type x</li>
<li>It can be a multiply of x and y, throwing away the answer.</li>
</ol>

Now, you might think the latter is stupid and should be ignored.
Most would agree with you; however, there are cases where it might
have a side effect (e.g., if multiply is overloaded). but that isn't the point.
The point is there are two different parses, and therefore a program
can mean different things depending on how this should have been parsed.

The compiler must accept the appropriate one under the appropriate circumstances, and in the absence of any other information (e.g., knowledge of the type of x) must collect both in order to decide later what to do. Thus a grammar must allow this. And that makes the grammar ambiguous.

Thus pure LR parsing can't handle this. Nor can many other widely available parser generators, such as Antlr, JavaCC, YACC, or traditional Bison, or even PEG-style parsers, used in a "pure" way.

There are lots of more complicated cases (parsing template syntax requires arbitrary lookahead, whereas LALR(k) can look ahead at most k tokens), but only it only takes one counterexample to shoot down pure LR (or the others) parsing.

Most real C/C++ parsers handle this example by using some
kind of deterministic parser with an extra hack: they intertwine parsing with symbol table
collection... so that by the time "x" is encountered,
the parser knows if x is a type or not, and can thus
choose between the two potential parses. But a parser
that does this isn't context free, and LR parsers
(the pure ones, etc.) are (at best) context free.

One can cheat, and add per-rule reduction-time semantic checks in the 
to LR parsers to do this disambiguation. (This code often isn't simple). Most of the other parser types
have some means to add semantic checks at various points
in the parsing, that can be used to do this.

And if you cheat enough, you can make LR parsers work for
C and C++. The GCC guys did for awhile, but gave it
up for hand-coded parsing, I think because they wanted
better error diagnostics.

There's another approach, though, which is nice and clean
and parses C and C++ just fine without any symbol table
hackery: <a href="http://en.wikipedia.org/wiki/GLR_parser" rel="noreferrer">GLR parsers</a>.
These are full context free parsers (having effectively infinite
lookahead). GLR parsers simply accept both parses,
producing a "tree" (actually a directed acyclic graph that is mostly tree like) 
that represents the ambiguous parse. 
A post-parsing pass can resolve the ambiguities.

We use this technique in the C and C++ front ends for our
DMS Software Reengineering Tookit (as of June 2017
these handle full C++17 in MS and GNU dialects).
They have been used to process millions of lines
of large C and C++ systems, with complete, precise parses producing ASTs with complete details of the source code. (See <a href="https://stackoverflow.com/a/17393852/120163">the AST for C++'s most vexing parse.</a>)

blocks|key|3145902|text|正如您在我的answer+here中看到的，C%2B%2B包含的语法无法由LL或LR解析器进行确定性解析，这是因为类型解析阶段(通常是解析后)更改了操作的顺序，从而改变了AST的基本形状(通常由第一阶段解析提供)。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|3145903|entityMap|0|LINK|mutability|MUTABLE|url|https://stackoverflow.com/questions/1172939/is-any-part-of-c-syntax-context-sensitive/1173038#1173038^0|6|B|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@$A|M|B|N|1|O]]|C|$]]|$1|D|3|-4|5|6|7|P|8|@]|9|@]|C|$]]]|E|$F|$5|G|H|I|C|$J|K]]]]

As you can see in my <a href="https://stackoverflow.com/questions/1172939/is-any-part-of-c-syntax-context-sensitive/1173038#1173038">answer here</a>, C++ contains syntax that cannot be deterministically parsed by an LL or LR parser due to the type resolution stage (typically post-parsing) changing the order of operations, and therefore the fundamental shape of the AST (typically expected to be provided by a first-stage parse).

blocks|key|3145953|text|问题从来不是这样定义的，而它应该是有趣的：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3145954|为了让“非上下文无关”的C%2B%2B解析器能够完美地解析这个新语法，需要对yacc语法进行最小限度的修改。(只使用了一个“hack”：typename/identifier消歧，解析器通知词法分析器每个类型定义/类/结构)|3145955|我看到了几个：|3145956|禁止使用|3145957|Type+Type;。声明为typename的标识符不能成为非typename标识符(请注意，struct+Type+Type不是模棱两可的，并且仍然可以被允许)。|ordered-list-item|offset|length|style|CODE|3145958|3145959|names+tokens有三种类型:|3145960|-+`types`+:+builtin-type+or+because+of+a+typedef/class/struct
-+template-functions
-+identifiers+:+functions/methods+and+variables/objects|code-block|syntax|javascript|3145961|将模板函数看作不同的标记，解决了func<的歧义问题。如果func是模板函数名，则<必须是模板参数列表的开头，否则func是函数指针，<是比较运算符。|3145962|3145963|Type+a(2);是一个对象实例化。prototypes.|3145964|int+(k);是完全禁止的函数，Type+a();和Type+a(int)是完全禁止的，应该写int+k;|3145965|typedef+int+func_type();和typedef+int+(func_type)();是禁止的。|3145966|3145967|函数类型定义函数必须是函数指针类型定义定义：typedef+int+(*func_ptr_type)();|3145968|template递归限制为1024，否则增加的最大值可能会作为选项传递给compiler.|unordered-list-item|3145969|
|3145970|int+a,b,c[9],*d,(*f)(),+(*g)()[9],+h(char);也会被禁止，由int+a,b,c[9],*d;+int+(*f)();替换|3145971|3145972|int+(*g)()[9];|3145973|int+h(char);|3145974|每个函数原型或函数指针声明一行。|3145975|一种非常优选的替代方案是改变糟糕的函数指针语法，|3145976|int+(MyClass::*MethodPtr)(char*);|3145977|正被重新综合为：|3145978|int+(MyClass::*)(char*)+MethodPtr;|3145979|这与强制转换操作符(int+(MyClass::*)(char*))|3145980|typedef+int+type,+*type_ptr;是一致的，也可能被禁止:每个类型定义符占一行。因此，它将成为|3145981|3145982|typedef+int+type;|3145983|typedef+int++*type_ptr;+|3145984|sizeof+int，sizeof+char，sizeof+long+long和co.可以在每个源文件中声明。因此，每个使用int类型的源文件都应该以|3145985|3145986|#type+int+:+signed_integer(4)|3145987|并且unsigned_integer(4)将被禁止在该#type指令之外，这将是迈向愚蠢的sizeof+int歧义的一大步，该歧义存在于如此多的C%2B%2B+headers中|3145988|如果遇到使用歧义语法的C%2B%2B源代码，实现重新合成的C%2B%2B的编译器会将source.cpp也移动到ambiguous_syntax文件夹，并且会在编译它之前自动创建一个明确的翻译后的source.cpp。|3145989|如果你知道一些，请添加你模糊的C%2B%2B语法！|3145990|entityMap^0|0|0|0|0|0|A|1B|G|0|0|0|C|0|0|G|5|T|4|15|1|1L|4|1V|1|0|0|0|A|0|0|8|H|9|R|B|1C|6|0|0|O|P|Q|0|0|M|V|0|0|0|0|17|1E|G|1V|B|0|0|0|E|0|0|C|0|0|0|0|X|0|0|0|Y|0|9|P|0|0|S|0|0|0|H|0|0|N|0|0|A|B|B|N|G|1Q|3|0|0|0|T|0|2|J|R|5|19|A|0|Y|A|1C|G|2I|A|0|0^^$0|@$1|2|3|4|5|6|7|2G|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|2H|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|2I|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|2J|8|@]|9|@]|A|$]]|$1|H|3|I|5|J|7|2K|8|@$K|2L|L|2M|M|N]|$K|2N|L|2O|M|N]]|9|@]|A|$]]|$1|O|3|-4|5|6|7|2P|8|@]|9|@]|A|$]]|$1|P|3|Q|5|6|7|2Q|8|@$K|2R|L|2S|M|N]]|9|@]|A|$]]|$1|R|3|S|5|T|7|2T|8|@]|9|@]|A|$U|V]]|$1|W|3|X|5|6|7|2U|8|@$K|2V|L|2W|M|N]|$K|2X|L|2Y|M|N]|$K|2Z|L|30|M|N]|$K|31|L|32|M|N]|$K|33|L|34|M|N]]|9|@]|A|$]]|$1|Y|3|-4|5|6|7|35|8|@]|9|@]|A|$]]|$1|Z|3|10|5|J|7|36|8|@$K|37|L|38|M|N]]|9|@]|A|$]]|$1|11|3|12|5|J|7|39|8|@$K|3A|L|3B|M|N]|$K|3C|L|3D|M|N]|$K|3E|L|3F|M|N]|$K|3G|L|3H|M|N]]|9|@]|A|$]]|$1|13|3|14|5|J|7|3I|8|@$K|3J|L|3K|M|N]|$K|3L|L|3M|M|N]]|9|@]|A|$]]|$1|15|3|-4|5|6|7|3N|8|@]|9|@]|A|$]]|$1|16|3|17|5|6|7|3O|8|@$K|3P|L|3Q|M|N]]|9|@]|A|$]]|$1|18|3|19|5|1A|7|3R|8|@]|9|@]|A|$]]|$1|1B|3|1C|5|6|7|3S|8|@]|9|@]|A|$]]|$1|1D|3|1E|5|1A|7|3T|8|@$K|3U|L|3V|M|N]|$K|3W|L|3X|M|N]|$K|3Y|L|3Z|M|N]]|9|@]|A|$]]|$1|1F|3|-4|5|6|7|40|8|@]|9|@]|A|$]]|$1|1G|3|1H|5|6|7|41|8|@$K|42|L|43|M|N]]|9|@]|A|$]]|$1|1I|3|1J|5|6|7|44|8|@$K|45|L|46|M|N]]|9|@]|A|$]]|$1|1K|3|1L|5|6|7|47|8|@]|9|@]|A|$]]|$1|1M|3|1N|5|6|7|48|8|@]|9|@]|A|$]]|$1|1O|3|1P|5|6|7|49|8|@$K|4A|L|4B|M|N]]|9|@]|A|$]]|$1|1Q|3|1R|5|6|7|4C|8|@]|9|@]|A|$]]|$1|1S|3|1T|5|6|7|4D|8|@$K|4E|L|4F|M|N]]|9|@]|A|$]]|$1|1U|3|1V|5|6|7|4G|8|@$K|4H|L|4I|M|N]]|9|@]|A|$]]|$1|1W|3|1X|5|1A|7|4J|8|@$K|4K|L|4L|M|N]]|9|@]|A|$]]|$1|1Y|3|-4|5|6|7|4M|8|@]|9|@]|A|$]]|$1|1Z|3|20|5|6|7|4N|8|@$K|4O|L|4P|M|N]]|9|@]|A|$]]|$1|21|3|22|5|6|7|4Q|8|@$K|4R|L|4S|M|N]]|9|@]|A|$]]|$1|23|3|24|5|1A|7|4T|8|@$K|4U|L|4V|M|N]|$K|4W|L|4X|M|N]|$K|4Y|L|4Z|M|N]|$K|50|L|51|M|N]]|9|@]|A|$]]|$1|25|3|-4|5|6|7|52|8|@]|9|@]|A|$]]|$1|26|3|27|5|6|7|53|8|@$K|54|L|55|M|N]]|9|@]|A|$]]|$1|28|3|29|5|6|7|56|8|@$K|57|L|58|M|N]|$K|59|L|5A|M|N]|$K|5B|L|5C|M|N]]|9|@]|A|$]]|$1|2A|3|2B|5|6|7|5D|8|@$K|5E|L|5F|M|N]|$K|5G|L|5H|M|N]|$K|5I|L|5J|M|N]]|9|@]|A|$]]|$1|2C|3|2D|5|6|7|5K|8|@]|9|@]|A|$]]|$1|2E|3|-4|5|6|7|5L|8|@]|9|@]|A|$]]]|2F|$]]

The problem is never defined like this, whereas it should be interesting :

what is the smallest set of modifications to C++ grammar that would be necessary so that this new grammar could be perfectly parsed by a "non-context-free" yacc parser ? (making use only of one 'hack' : the typename/identifier disambiguation, the parser informing the lexer of every typedef/class/struct)

I see a few ones:

<ol>
<li><code>Type Type;</code> is forbidden. An identifier declared as a typename cannot become a non-typename identifier (note that <code>struct Type Type</code> is not ambiguous and could be still allowed).

There are 3 types of <code>names tokens</code> :

<ul>
<li><code>types</code> : builtin-type or because of a typedef/class/struct</li>
<li>template-functions</li>
<li>identifiers : functions/methods and variables/objects</li>
</ul>

Considering template-functions as different tokens solves the <code>func&lt;</code> ambiguity. If <code>func</code> is a template-function name, then <code>&lt;</code> must be the beginning of a template parameter list, otherwise <code>func</code> is a function pointer and <code>&lt;</code> is the comparison operator.</li>
<li><code>Type a(2);</code> is an object instantiation. 
<code>Type a();</code> and <code>Type a(int)</code> are function prototypes.</li>
<li><code>int (k);</code> is completely forbidden, should be written <code>int k;</code></li>
<li><code>typedef int func_type();</code> and 
<code>typedef int (func_type)();</code> are forbidden. 

A function typedef must be a function pointer typedef : <code>typedef int (*func_ptr_type)();</code></li>
<li>template recursion is limited to 1024, otherwise an increased maximum could be passed as an option to the compiler.</li>
<li><code>int a,b,c[9],*d,(*f)(), (*g)()[9], h(char);</code> could be forbidden too, replaced by <code>int a,b,c[9],*d;</code>
<code>int (*f)();</code> 

<code>int (*g)()[9];</code> 

<code>int h(char);</code> 

one line per function prototype or function pointer declaration.

An highly preferred alternative would be to change the awful function pointer syntax, 

<code>int (MyClass::*MethodPtr)(char*);</code> 

being resyntaxed as:

<code>int (MyClass::*)(char*) MethodPtr;</code> 

this being coherent with the cast operator <code>(int (MyClass::*)(char*))</code></li>
<li><code>typedef int type, *type_ptr;</code> could be forbidden too : one line per typedef. Thus it would become

<code>typedef int type;</code> 

<code>typedef int *type_ptr;</code> </li>
<li><code>sizeof int</code>, <code>sizeof char</code>, <code>sizeof long long</code> and co. could be declared in each source file.
Thus, each source file making use of the type <code>int</code> should begin with

<code>#type int : signed_integer(4)</code>

and <code>unsigned_integer(4)</code> would be forbidden outside of that <code>#type</code> directive
this would be a big step into the stupid <code>sizeof int</code> ambiguity present in so many C++ headers</li>
</ol>

The compiler implementing the resyntaxed C++ would, if encountering a C++ source making use of ambiguous syntax, move <code>source.cpp</code> too an <code>ambiguous_syntax</code> folder, and would create automatically an unambiguous translated <code>source.cpp</code> before compiling it.

Please add your ambiguous C++ syntaxes if you know some!

blocks|key|356980|text|C%2B%2B中的“类型定义”问题可以通过在解析时构建符号表的LALR(1)解析器(而不是纯粹的LALR解析器)来解析。“模板”问题可能无法用这种方法解决。这种LALR(1)解析器的优点是语法(如下所示)是LALR(1)语法(没有歧义)。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|356981|/*+C+Typedef+Solution.+*/

/*+Terminal+Declarations.+*/

+++<identifier>+=>+lookup();++/*+Symbol+table+lookup.+*/

/*+Rules.+*/

+++Goal++++++++->+[Declaration]...+<eof>+++++++++++++++%2B>+goal_

+++Declaration+->+Type...+VarList+';'++++++++++++++++++%2B>+decl_
+++++++++++++++->+typedef+Type...+TypeVarList+';'++++++%2B>+typedecl_

+++VarList+++++->+Var+/','...+++++
+++TypeVarList+->+TypeVar+/','...

+++Var+++++++++->+[Ptr]...+Identifier+
+++TypeVar+++++->+[Ptr]...+TypeIdentifier+++++++++++++++++++++++++++++++

+++Identifier+++++->+<identifier>+++++++%2B>+identifier_(1)++++++
+++TypeIdentifier+->+<identifier>++++++=%2B>+typedefidentifier_(1,{typedef})

//+The+above+line+will+assign+{typedef}+to+the+<identifier>,++
//+because+{typedef}+is+the+second+argument+of+the+action+typeidentifier_().+
//+This+handles+the+context-sensitive+feature+of+the+C%2B%2B+language.

+++Ptr++++++++++->+'*'++++++++++++++++++%2B>+ptr_

+++Type+++++++++->+char+++++++++++++++++%2B>+type_(1)
++++++++++++++++->+int++++++++++++++++++%2B>+type_(1)
++++++++++++++++->+short++++++++++++++++%2B>+type_(1)
++++++++++++++++->+unsigned+++++++++++++%2B>+type_(1)
++++++++++++++++->+{typedef}++++++++++++%2B>+type_(1)

/*+End+Of+Grammar.+*/|code-block|syntax|javascript|356982|可以毫无问题地解析以下输入：|356983|+typedef+int+x;
+x+*+y;

+typedef+unsigned+int+uint,+*uintptr;
+uint++++a,+b,+c;
+uintptr+p,+q,+r;|356984|LRSTAR+parser+generator读取上面的语法表示法并生成一个解析器，该解析器在解析树或语法分析树中不会有歧义地处理“类型定义”问题。(披露:我就是那个创建LRSTAR的人。)|offset|length|356985|entityMap|0|LINK|mutability|MUTABLE|url|http://lrstar.tech/^0|0|0|0|0|0|N|0|0^^$0|@$1|2|3|4|5|6|7|W|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|X|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|Y|8|@]|9|@]|A|$]]|$1|I|3|J|5|D|7|Z|8|@]|9|@]|A|$E|F]]|$1|K|3|L|5|6|7|10|8|@]|9|@$M|11|N|12|1|13]]|A|$]]|$1|O|3|-4|5|6|7|14|8|@]|9|@]|A|$]]]|P|$Q|$5|R|S|T|A|$U|V]]]]

The "typedef" problem in C++ can be parsed with an LALR(1) parser that builds a symbol table while parsing (not a pure LALR parser). The "template" problem probably cannot be solved with this method. The advantage of this kind of LALR(1) parser is that the grammar (shown below) is an LALR(1) grammar (no ambiguity). 

<pre><code>/* C Typedef Solution. */

/* Terminal Declarations. */

 &lt;identifier&gt; =&gt; lookup(); /* Symbol table lookup. */

/* Rules. */

 Goal -&gt; [Declaration]... &lt;eof&gt; +&gt; goal_

 Declaration -&gt; Type... VarList ';' +&gt; decl_
 -&gt; typedef Type... TypeVarList ';' +&gt; typedecl_

 VarList -&gt; Var /','... 
 TypeVarList -&gt; TypeVar /','...

 Var -&gt; [Ptr]... Identifier 
 TypeVar -&gt; [Ptr]... TypeIdentifier 

 Identifier -&gt; &lt;identifier&gt; +&gt; identifier_(1) 
 TypeIdentifier -&gt; &lt;identifier&gt; =+&gt; typedefidentifier_(1,{typedef})

// The above line will assign {typedef} to the &lt;identifier&gt;, 
// because {typedef} is the second argument of the action typeidentifier_(). 
// This handles the context-sensitive feature of the C++ language.

 Ptr -&gt; '*' +&gt; ptr_

 Type -&gt; char +&gt; type_(1)
 -&gt; int +&gt; type_(1)
 -&gt; short +&gt; type_(1)
 -&gt; unsigned +&gt; type_(1)
 -&gt; {typedef} +&gt; type_(1)

/* End Of Grammar. */
</code></pre>

The following input can be parsed without a problem:

<pre><code> typedef int x;
 x * y;

 typedef unsigned int uint, *uintptr;
 uint a, b, c;
 uintptr p, q, r;
</code></pre>

The <a href="http://lrstar.tech" rel="nofollow noreferrer">LRSTAR parser generator</a> reads the above grammar notation and generates a parser that handles the "typedef" problem without ambiguity in the parse tree or AST. (Disclosure: I am the guy who created LRSTAR.)

I was reading about parsers and parser generators and found this statement in wikipedia's LR parsing -page:

<blockquote>
 Many programming languages can be parsed using some variation of an LR parser. One notable exception is C++.
</blockquote>

Why is it so? What particular property of C++ causes it to be impossible to parse with LR parsers?

Using google, I only found that C can be perfectly parsed with LR(1) but C++ requires LR(∞).

Why can't C++ be parsed with a LR(1) parser?

编译器

我在阅读有关解析器和解析器生成器的文章时，在维基百科的LR解析-page中找到了这句话：许多编程语言都可以使用LR解析器的某些变体进行解析。一个值得注意的例外是C++。为甚麽呢？C++的什么特殊属性导致它无法使用LR解析器进行解析？使用谷歌，我只发现C可以完美地解析为LR(1)，但C++需要LR(∞)。

问为什么不能用LR(1)解析器解析C++？
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问为什么不能用LR(1)解析器解析C++？EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问为什么不能用LR(1)解析器解析C++？
EN