※ 引述《[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 》──┘ 　 ◤ 唱片公司授權，音樂盡情下載 --