※ 引述《[email protected] (汀)》之铭言： > debugger 在 yacc 的状况是， > 会混着 .y 跟 .c 在跳， > 这是因为 yacc 在 .c file 里面插入了一堆 #line 123 "xxx.y" 这种东西， > 可是这时你就会有一个麻烦， > 相信你也知道 .y 常常是这样写的： > rule1: > xxxx yyyy zzzz > { > /* 超大一片 C code */ > } > | aaa bbb > { > /* 又是超大一片 C code */ > } > | ... perly.y: expr : expr ANDOP expr { $$ = newLOGOP(OP_AND, 0, $1, $3); } | expr OROP expr { $$ = newLOGOP($2, 0, $1, $3); } | argexpr %prec PREC_LOW ; 好大片 C code 啊, 会写一大片是 programmer 的问题, grammar 加上条件的 parser 远比纯用 grammar 语法应干来得精简 perl 是本来就不能 BNF, 一开始就不打算用 grammar 解掉 parser C++ 用纯粹 LL 写的人大概都是学术界, 这种 parser 的 cpu/memory cost 怎麽估啊 parser 还是做 interpreter 的人写得好 > 这年头会因为这样就挂掉的 compiler 不多了， > 除非你还在用 VC6 跟 gcc 2.95.x。 我是做 embedded system, boost 好不好 crosscompile 有目共赌 目前大概只有 PPC linux, PPC OSX 能用 compiler, libc 都要特定版本才能用, 这就是可移植性不佳 PC 以外还是有 compiler/interpreter 要跑的 > 上面已经不是说了， > 是用的「技术」比较先进， > 让该在一起的东西在一起， > 不该混在一起的就分开来 (grammar 跟 action)， > 进而获得不想 step into 就可以 next 掉的 debugging 优势。 就算要用 LL 好了 ( LL 并没有「技术」比较先进, 很多东西 LALR 较精简) spirit 还是远不如 ANTLR 因为 spirit 是借用 C++ template, 所以很多 4GL compile time 的问题, 在 spirit 变成 runtime 才会发生, 如不小心写成 LR, 语法有矛盾等错误 > 不对， > 这是因为 spirit 故意选择了 recursive descent parsing， > 为什麽？ > 因为合乎人类的直觉， > 所以也因此更容易 debug (容易 debug 的理由又多了一个)。 > GCC 4.x 也选择了「纯手工」打造的 LL(1) parser， > boost::spirit 则选择了「半手工」打造的途径， > 并不能说 LL 在课本上比 LR 早出现， > 而 LR 可以比 LL 少改一些文法， > 就说 LL 比较落後， > LL 跟 LR 各有优缺点， > 而它们的优劣差异可以大到让人们分成两大派系， > 所以拿 LL 跟 LR 来区分先进与落後是不恰当的。 > > MIPS, ARM, PPC, FR 都有标准, 但 C++ 各家 compiler 差太多, 怎麽定 > > 一个 pointer to class method 就有 n 种作法 > 这是因为 C++ 保留给编译器厂商实作的弹性， > 不过这东西其实跟 C 一样有办法针对各 architecture 制订公约， > 只是 C++ 从来就不曾如 C 这麽盛行过， > 所以设计 arch. 的公司也没有什麽兴趣去订。 > 标准规格书说「保留给编译器实作」这件事， > 并不是真正代表「什麽都看 compiler 高兴怎样就怎样」， > 只要 C++ 能跟 C 一样深具影响力， > arch. 的厂商还是会像 C 那样订出一套公约让大家遵循。 C 的 stack, calling convention 是 " 对外 " 的事 C 发明就是为了写 OS, 写 library, dynamic linking 才会让程式的开头是一个 crt0.o 去叫 main() 就算没有文件大家还是会做得差不多 C++ 的 object method 只在内部使用, 无法给出来变 library, 所以大家当然各作各的, 这是不一样的 所谓 OS ABI Application Binary Interface 顾名思义, 是 Binary, 要向下相容, C++ 目前办不到, 以後如果定了, 现在写的 code 又怎麽办 所以 OS 不能用 C++, C++ 一开始就走错了, 就如语法不能 100% BNF, 来不及, 没得回头, 业界不是学术界, 做东西只是为了证明自己的理论 写的 code 当然以後要能用, 卖的 binary 当然要换 compiler 还能 link 大家要靠 C 的 OS 提供一致的 ABI&data structure > native 的东西本来就会面临到「要自己写一个 OS 才能支援」的问题， > 问题是「新的 OS 要能盛行」是一件不容易的事情， > 首当其冲的就是 driver 的支援， > 写出王道的 OS 但是各家硬体厂商不甩你， > 2007 年的现在要说服这些硬体厂商 support 你实在很难， > 要说服众多懂得写各家 hardware driver 的 hackers 来 support 更难， > 最後不管写得多王道最後都只会被埋没而已， > 这也是为什麽要 VM 执行的语言跟 native 执行的语言不应比输赢的原因之一， > 只能说各有利弊， > 在正确的场合选择对的就好了。 > > 造成很多 GUI 程式的 callback 大改, 又无法 binary 相容 > 这是一开始就存在且已知的问题， > 并不是要「大改」， > 还是一开始就要花费成本去「设计」， > 但是久了也会变成一个设计阶段的经验， > 成为 maintain 成本的只有「无法 binary 相容」， > 但这本来就是 native code 的宿命， > 除非先去炸了 Microsoft 跟各家 *nix 大厂。 -- ┌─────◆ＫＫＣＩＴＹ◆─────┐ ◢　◤ 听 KKBOX，动态歌词紧紧跟着你 │ bbs.kkcity.com.tw │ \^_^ / ★ http://www.kkbox.com.tw ★ └──《From:122.124.16.239 》──┘ 　 ◤ 唱片公司授权，音乐尽情下载 --