※ 引述《[email protected] ( )》之铭言： > parser 只是负责把 C++ code 转成内部 structure, > 会出问题通常是内部表示 data structure 没规划好 > 因为 template/class 产生的资料量超大, worst case 没估好爆掉 > 不然就是写的人误解 C++ 语法 > C++ 对人应该是比对机器复杂, 人可记不得那麽多解读优先顺序 > 可以用 BNF 都算好 parse 当初 GCC 就是因为没办法 parse C++ 所有正确的 syntax， 才被大家逼到整个重写的， parser 这东西没有你所想像的简单， 因为软体开发常常是渐进式的， 而标准制订过程本身也是渐进式的， parser 的开发不可能一开始就规划好全套， 通常都是先做一个 subset， 然後随着时间演进慢慢加慢慢修， tool 太弱的话遇上「变」就会出事。 在 C++ syntax 被证明成可用 LL(1) 实作之前， 很多人都在猜 C++ parser 没有 LR(2) 搞不出来， 因为许多人使用 bison 这个 LALR(1) parser generator 实作都碰壁得很惨， 不单是 LALR 和 LR 支援 syntax 的能力之差所造成的错觉， 还常常会遇上 lookahead 的 token 不够的问题。 一个 grammer 能用 BNF 表示， 并不会代表它的 parser 好写， 因为 BNF 可以随你高兴写， 但写出来的 form 不见得适合 context-free LALR(1) parser 去 parse。 > 因为 MACRO 不能搞一大片 code, 写的时候就会避免了 > 在 C++ 也还是可以用 define, 烂人还不是照用 但很遗憾的是许多人看好的 GCC 还是很爱使用它， 打开 GCC 的 source code， 你就是会看到这麽一大片 macro， 只能说随着年龄增长会让人对新技术的接受能力下降， 导致 GNU 的守旧派人士一直都没有长进， 让 80 年代的 programming 技术仍活在 free software 的 source code 里。 > 再加上继承, overloading 这些可能跨过无数 header, source > 追进去早忘了上层是啥 datatype debugger 有 list overloaded functions 的能力， 也有指定 break 在哪个 overloaded functions 的能力， template instances 也不例外， 在哪个 file 其实根本不重要， 档名当你需要知道的时候下个指令就会出来了， 刚跳进去的时候通常也会自动显示。 至於继承这种东西， 其实也没有你想像中的难追， 这和你一再强调的设计方法有关， 反过来说 debug/trace 别人程式得先了解其设计方法， 就像正统的 OO 设计一样， programmer 根本不需要去关心上层 type 是什麽， C++ 在 compile-time 就已经帮你确立了 type-safe， 除非设计程式的人乱搞， 不然你根本没有必要知道它的实际 type， 事实上如果真的因为 debugging 需要， 你可以放一个识别 type 用的 virtual member function 来辅助。 > 自己写的 template 难道不用 debug? 我前面不是说了， template 可以 step into， 而且我是讲「使用人家的 library」时不需要 step into 去看里面， 既然是自己写的当然要进去看， 但 macro 就无法这样追。 > 用 STL 套在自己的 class 上不用 trace? 是的，不用 trace 进去 STL 的内部实作， 就像你用继承/合成方法扩充 library 的某个 base class， 而它的 base class 实作码是不可见的一样， 你没有必要也没有办法看到 base class 的实作码。 如果今天你是在一个完整且正确支援 export 的 compiler 里， 且其 STL 的实作码在 header file 中完全不可见， 而 library 本身也被 strip 过， 你一样是没办法也没必要看到那里面去， 你只要看呼叫的结果就可以了， template 只不过是一种静态多型的表现方法， 没有理由对它 debug 要比对动态多型的程式还复杂， 只是许多人被目前的 environment 所蒙蔽了。 > 无法预期会挂在那才会去 trace, 当然要任何点都能 trace > 不然 assembly level trace 做给谁用 做给 compiler 设计者用， 还有一些想 tune 自己 application 效能的人用。 这种 trace 的方向根本就是偏了， 无法预期挂在哪里的问题， 就算用这种方法也一样找不出来， 只是浪费时间而已。 就跟 C programming 一样， function 文件的 pre-condition 和 post-condition 可不是写好玩的。 > 所以用 template 写东西, 不能 crossplatform, 连 compiler version 都有差 > 产生的语法错误讯息还超难懂, 熟也只能熟一个 compiler 不对，用 template 写东西绝对可以 cross， 一直以来都没有问题， 而且要同时让支援 export 跟不支援 export 的 compiler 都不会有问题， 讲 template 的书上也有说明做法， 我还是第一次听说用 template 写的东西不能 cross platform。 > C++ 做过头, 规定太多, 才会有 java, c# 跑出来 你搞反了， 是 C++ 太自由， 所以规定太多的 Java 和 C# 才会跑出来， 给 programmer 许多比「公约」更严的语言性限制。 > 真正优良的程式靠的是规划, 用那一种 library, tool, language 都没用 > 第一个 pascal compiler 用 pascal 写, > 第一个 java compiler 用 java 写, > compiler 跟语言本身一起完成, 靠的就是切割得好 我想你可能没有抓到问题的重点， 原 po 问的是用 lex/yacc 好不好， 表示这时他已经选择了「工具」， 突然讲「程式规划」会让人感觉是来乱的， 并不是说「程式规划」不重要， 而是说「程式规划」在目前的这个主题而言不重要， 我要说的是 lex/yacc 这个工具很老旧， 我们有更好的工具可以用， 有更好的工具自然也能让 programmer 更专注於程式规划和设计上， 这两者并不冲突， 不管开发任何程式都需要使用工具， 不单只是 library 和 code generator， language 本身也是一种工具， 在规划程式之前如果不正确的选择好工具， 那也只是纸上谈兵罢了， 要知道同样是 OO 设计， C++、C#、Java 的表现方式就大不相同， 这其中牵涉到很多细节， 像是 C++ 的 constructor/destructor 不能 call virtual function 这类事情， 还有 C++ 对「介面继承」及「实作继承」的表现方式也和 C#、Java 不同等因素， 这都是 language 这个工具所造成的差异性， 而 library 和 code generator 这些 tools 的选择， 也都是初期就应该决定好的， 因为它会影响到你的分析和设计， 尤其是 code generator， 因为如果它生出来的是 legacy code， 你还要准备好各种 workaround 来应付它， 而这个准备动作也是程式规划的一环。 -- 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 -- ╔═══╗ ┼────────────────────────╮ ║狂狷 ║ │＊ Origin：[ 狂 狷 年 少 ] whshs.cs.nccu.edu.tw ╰─╮ ║ 年少║ ┼╮ < IP：140.119.164.252 > ╰─╮ ╚╦═╦╝ ╰ ＊ From：61-230-229-51.dynamic.hinet.net ─╨─╨─ ＫＧＢＢＳ ─ ◎ 遨翔"BBS"的狂狷不驯；属於年少的轻狂色彩 ◎ [修改]tinlans:61-230-229-51.dynamic.hinet.net 07/04/18 21:06:29