※ 引述《[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 》──┘ 　 ◤ 唱片公司授权，音乐尽情下载 --