※ 引述《halajohn (Wei Hu)》之铭言： : : 很多人都在猜 C++ parser 没有 LR(2) 搞不出来， : : 因为许多人使用 bison 这个 LALR(1) parser generator 实作都碰壁得很惨， : : 不单是 LALR 和 LR 支援 syntax 的能力之差所造成的错觉， : 挑个错, LALR or LR 支援 syntax 的能力并不差, : 理论上 (实际上也是), LR 要比 LL 强大 (的多). 你好像没看懂我的意思， 还是说你截错位置了， 第一句的「在 C++ syntax 被证明成可用 LL(1) 实作之前」你似乎没看到， 所谓「在 xxx 被证明可用 LL(1) 实作之前，很多人都在猜没有 LR(2) 搞不出来」， 意思就是说 LR(2) 处理能力较强， 所以一堆人以为 C++ syntax 复杂到 LR(2) 才能解， 结果居然有人证明出来 LL(1) 就能搞定了， 原文合起来就是这样的意思而已。 另一个你可能误会的是「能力之差」四个字， 可能是我用词不当， 它的意思是指「能力上的差距」， 所谓的「差」是指 difference 不是指 bad。 : : 还常常会遇上 lookahead 的 token 不够的问题。 : lookahead 的问题不在够不够用, : 要是觉得不够用, 你自己把他加大不就好了. : lookahead 的问题在於, 大於某个数值的 lookahead 下, : grammar 展开的时间 (或空间, 看你要用哪种实作) 将会大到超过你的想像, : 就连目前个人电脑上能用到的最快 CPU 也没法轻易的负担. : 而这个数值在现实生活中所用到的一般性 grammar 而言, : 大约是 2.... 这时 parser generator 的劣势就会出现了， 手工或利用 library 制成的 parser 有办法偶尔偷作弊往前看几个 token， 但 parser generator 就比较难做到这种弹性， 因此会对 lookahead 的 token 数有相当硬性的限制。 : 理论上是这样啦, 不过要 100% 支援 C++ 的 compiler 才行 在 2005 年之後， 这个理论早已成为事实， 除了 export 的特性之外。 : 我个人很喜欢写 template code, : 之前用 gcc 3 写, 一些复杂的 syntax 都做不出来 : (不知道 gcc 4 有没有因为 parser 换过所以好点). 好非常多了， 就算有 bug 你报上去也修得非常快， 不像以前 parser 有 bug 只能一整个摆烂。 : 现在改用 VC 2005... : 说真的, Microsoft 做得还真不错, 不是盖的, 100 分. -- Name: Tseng, Ling-hua E-mail Address: [email protected] School: National Tsing Hua University Department: Computer Science Interesting: C++, Compiler, PL/PD, OS, VM, Large-scale software design Researching: Software pipelining for VLIW architectures Homepage: https://it.muds.net/~uranus --

※ 发信站: 批踢踢实业坊(ptt.cc) ◆ From: 61.230.226.51 ※ 编辑: tinlans 来自: 61.230.226.51 (04/19 18:02)