※ 引述《[email protected] (汀)》之銘言： > 每年參與 GCC Developers' Summit 的人都是業界人士居多， > 而 GCC 改用 LL parser 時確實在 mailing list 上引起了這方面的討論， > 最後 GCC 還是在 release 的時候烙了一句： > The old Bison-based C and Objective-C parser has been replaced by a new, > faster hand-written recursive-descent parser. hand-written 當然 faster, 不是說用 LL grammar faster, 為了 faster 而用 3GL 硬幹也是我說過的兩種極端之一 LL 跟 LALR 的 performance 並無差別, 一個 top-down 一個 buttom-up 兩種不同哲學, 就如開一家汽車工廠 buttom-up 的會先賣輪胎, 引擎 (japan), top-down 先賣設計圖, 車殼 (us) > 到現在為止 faster 這個字都還沒怎麼被嗆過， > 因為 parsing 的速度確實變快了； > 要「估」CPU/memory cost 的才是學術界在做的， > 這種在世界上擁有廣泛 users 的 compiler 實作者， > 都是用實驗去「量」的， > 睜眼說瞎話這麼久的話可不會有人默不作聲， > 確實是有 speedup 這個 implement 才能生存下來。 > 我前面針對這篇回你的那些 compiler 公司， > 我想你應該都聽過而且它們都是做 embedded system cross-compiler 的， > 人家可是把 standard C++ 支援得好好的， > C/C++ library 也幫你弄得好好的， > 想要用 boost 這種不太舊的東西的人， > 好歹也應該搭個不會太舊的 toolchain 比較合理吧？ 跟新舊無關, 最新的 STLport & uClibc 是會掛點的 要用舊的才能, 但 sigc++ 又不一定了 所以 toolchain 是現實問題, 不是 upgrade 會好的 PIC, 8051, DSP 更是沒別的 toolchain 可選 > LL 不太可能不小心寫成 LR， > 至少用 spirit 非常困難， > 因為整個實作上的程式架構就差太多了。 > spirit 會在 runtime 才發生的問題， > 不會是因為借用 C++ template 導致的， > 而是 C++ 本身為了 runtime 的 performance， > 堅持不在 runtime 做多餘的 checking 所造成的； yacc or ANTLR 等 4GL 在 compile time 就能找出該 grammar 有無定義失當 spirit 無法, 是因為 C++ compiler 又不認識 LL, 關 runtime 做多餘的 checking 什麼事 > 只要 OS 跟 architecture 設計者沒規定， > 各家 compiler 廠商也都沒有公約的話， > 每個 compiler 設計者都能將它視為最佳化演算法的一部份， > 以自己的考量來訂定它。 C 只要一開始有一個 compiler 出來, 賣 library 針對它寫了 library 後面的 compiler 非要能跟它 link, calling convention 自然一樣, 要能用之前的 header file, data structure 自然一樣 > > C++ 的 object method 只在內部使用, 無法給出來變 library, > > 所以大家當然各作各的, 這是不一樣的 > 我不懂「只在內部使用」的意思， 就是 C++ 沒有把 class 做成 binary library 的機制 因為 static typing 不能繼承 binary class, 也沒 reflection 如果真的一切向方便看齊, obj C 遠比 C++ 好用, dynamic typing 也不過就比 static typing 多吃一點點 cpu, apple 就是 objC 擁護者, 但是也沒別人了 lisp/forth 的 template 也比 C++ 強大, 但是 C++ 為何較多人用? 看起來要像 C 就是程式語言的包袱 -- ┌─────◆ＫＫＣＩＴＹ◆─────┐ ◢　◤ 動態歌詞 讓你成為Ｋ歌之王! │ bbs.kkcity.com.tw │ \^_^ / ★ http://www.kkbox.com.tw ★ └──《From:122.124.16.239 》──┘ 　 ◤ 唱片公司授權，音樂盡情下載 --