※ 引述《[email protected] ( )》之铭言： > ※ 引述《[email protected] (汀)》之铭言： > > 我印象中 BNF 可以描述 context-sensitive 的 syntax， > > 受到较多限制的 BNF 才会变成 context-free 和 regular expression， > > 所以我才说 BNF 可以高兴怎样写就怎样写， > > 但是 parser 不见得做得出来。 > 举个例子? 能用 BNF 不能用 machine 做 parse 的语法? > 不能 compile 是有的, 如 int a[100000000000000] > 很多 code gen 和 library 都是直接用 BNF 语法的 你好像已经忘记我更前面说「context-free LALR(1) parser」了： 一个 grammer 能用 BNF 表示， 并不会代表它的 parser 好写， 因为 BNF 可以随你高兴写， 但写出来的 form 不见得适合 context-free LALR(1) parser 去 parse。 换句话说我只要随便举个 context-sensitve 的 BNF， context-free LALR(1) parser 就 parse 不出来， 这跟「不能用 machine 做 parse」是不一样的意思。 > > 我讲的 80 年代 programming 技术， > 3GL 是 50 年代 programming 技术, template 从 lisp(196x), forth 就有 > OO 语言的历史比 C 还久, smalltalk(1969) 就有 dynamic typing > yacc 远比 template, OO 先进得多! 只不过是去 parse 一个 .y file， 然後照内订的机制去产生 .c 和 .h， 再摆上一堆 #line 进去辅助 debug 而已， 可惜这堆 #line 也拯救不了它产生出来的 code 难 debug 的特性， 相信你有用 debugger 跳进去看过的话应该就会有所感想。 比较晚写出来并不代表它比较先进， 名词比较早出来并不代表它永远比较落後， 但是一样东西从出来到现在都没有改变， 却显然是落後的一种证明。 何况 parser generator 跟 language 谁早谁晚， 并不会代表早的一方比较先进， 今天用 C++ 的 boost::spirit library 写出的 parser， 显然就是比 yacc generator 出来的 parser 容易 debug， 因为 boost::spirit 用的技术比较先进 (无关它是否较晚被做出来)， 而 yacc 使用的技术却一直停留在旧时代， 如此而已。 > C++ 只是把这些 196x-197x 的东西换个用辞, 大家基本上停留在 3GL > 旧没有不好, 像 assembly 还不是要学会, 旧的东西本来就没有不好， 但是没有随着技术进步而更新实作内容就是不好 (白话就是不长进)， 工程上 legacy system 本来就是一个很沈重的负担。 assembly 永远不是旧的东西， 每当一个新的 CPU 被设计出来， 新的 assembly language 也再次出现， 一个 8051 assembly 超强的人， 看到 ARM 的 assembly code 一样几乎等於要重学， 看到 IA64 或是其它各种 VLIW architecture 的 assembly code 一样几乎要重学， 以前写 assembly code 的人根本管它什麽 pipeline hazard， 现在你不管它写下去跑出来保证答案乱七八糟。 assembly 不是旧的东西， 它是一个相当基础的存在， yacc 和它并不能相提并论， 因为有各种和 yacc 同 level 的 tools 可以取代它， 但如果没有 assembly language， compiler 就必须直接跳过 assembler 直接生出 machine code， 你很难找出当今世上有什麽东西跟 assembly language 同 level， 又可以取代 assembly language 的东西。 > 商用 compiler 也还是在用 4GL, 含 yacc > 很多所谓的 "library" 是 4GL interpreter, 如 SQL > 写 compiler 用 4GL 很快很省事, bug 好不好抓跟程式架构有关, 这跟我看到的情形差很多， 商用的 compiler， 如 ACE Cosy、MetaWare 的 C/C++ Compiler Tool Suite、Target 的 CHESS， 还有 Altium TASKING 的 Viper， 它们的 front-end 都不是 4GL 做出来的。 > 不然 perl 和一堆无法 BNF 的语言 parser 为何大多用 yacc? 这理由很简单， 因为大部分 compiler 教科书都教人用 yacc， 而且都不愿意更新书本的内容教大家用其它 tools， 所以大部分修过 compiler 课程的人， 一听到 parser 第一个反应就是 yacc， 如同学过 data structure 的人一听到 postfix 就会想到 stack 一样， 而没修过 compiler 课程的人跑去问修过的人， 修过的人也如此反应回答 yacc， 这是久未更新的教科书所带来的原罪。 事实上讲白话一点， 你这个问题跟「为什麽现在的 OS kernel 很少用 C++ 撰写」是相同的， 答案其实简单到不行， 因为 C++ 盛行得很晚， 大家都用 C 写完了用 C++ 重写干嘛？ 再说 open source 的 kernel 也是用 C 写， 有现成的 C code 可以拿来抄干嘛自己设计？ 就算要自己设计， 教人写 kernel 的书都用 C 跟 ASM， 有范例可以抄来改谁会不抄， 当然还是用 C 跟 ASM。 所以， 为什麽一堆人用 yacc 的答案应该再明显不过了。 > > 指的是 yacc 这个工具 (无论是设计或是产生出来的 code)， > > 跟 C++ 是不是新东西倒没什麽关联性， > > 重点是 2007 年用 yacc 去生 parser 的 code 已经非常不合时宜了， > > 做 parser 有更方便更容易除错的 language-level library 可以使用。 > > 至於 public private protected friend 这类东西， > > 会不懂的大概也只剩下 10 年前还是学生的叔叔伯伯姑姑阿姨了， > 这些东西懂了吗? 记得了吗? > 继承以後的改变背起来了吗? 我第一次听说学写程式要用背的， 写程式是 close-book 的上机考吗？ 有书放在旁边可以翻不翻实在很奇怪， C++ 系列书籍的「原文中译本」在台湾算是非常齐了， 说没书也实在是很奇怪， 这东西跟你知道 double x = 1 / 5; 结果为什麽会是 0 一样， 有用到有遇到过几次就会熟了， 没有什麽是要特别去背的， 写程式写到要用背的就很可悲了。 > 不然 java 把 virtual 换成 interface 是为何, 照你上面讲的， 那还不是要去背 interface 跟 abstract 是什麽东西？ 还不是要背 interface 跟 abstract 还有啥都没写差在哪？ 事实上在 Java 也不是把 virtual 换成 interface， 而是把 C++ 某种 abstract base class 的特例制订成一个语言机制， interface 在 C++ 就是只含有 pure virtual function， 且没有任何 data members 的 abstract base class， 没有 constructor、有一个 pure virtual destructor (Java 无 destructor)； 这只是把一个 C++ 没有明确描述的东西用明确的语言机制去描述， 但同时也是带给 programmer 一个限制， 我想你应该也注意到了， interface 不能有 data members， 但是 C++ 可以， 这就是所谓的限制。 C++ 跟 Java 的取向不同， 赋予 programmers 自由和责任也大相迳庭， 要互相比较是很困难的。 > 常常有人 C++ 写完编不起来去乱 public, 这就是不用功和不读书的问题， 我也常常看到 Java programmer 的初学者， 人家写得好好的 factory method， 他当成是垃圾和多余的东西把它一整个砍下去 (嫌要写比较多 code)， 我也看到一堆人在 Java 想用多重继承结果用不出 (没读书不懂 Java 的精神)， 嫌 Java 难用把它丢了换 C++ (相当然尔这种态度一样学到烂掉)。 这根本是学习态度的问题， 跟使用哪种语言无关。 > 不然就是不知 call 得是 parent method 还是 child 这也是不看书造成的问题。 > C 语法就一点点还能用啥奇招? > 再奇怪也跳不出 C 语法呀, inline assembly 之类是写 OS 必需的, > C++ 不能写 OS, 又有不明确的 memory map, 自然少人用 inline assembly C++ 可以写 OS， 中正大学的 OS lab 就有人在用 C++ 写 OS， 随便 google 一下也会找到一个叫 unixlite 的 OS 是用 C++ 写的， 不要被无知的 Linus Torvalds 骗了 (有名而且说出这种话的几乎只有他)， 他根本不了解 C++。 我讲的不是什麽 inline assembly， 你说再奇怪也跳不出 C syntax 也没错， 但是偏偏就会出现一堆有的没的怪招来， 重复一次：「新语言机制」是因应「旧语言技巧」而产生的。 举例来说， 大家都认为 OO 有必要， 所以把 OO 做进了新的语言里， C 不支援 OO， 但是可以模拟 OO (用上极其大量且怪异的设计方法以及 macros)， 而且可以用「各式各样的方法」去模拟 OO， 你几乎可以说是换一个 team 就要重学一套 (如果你有需要扩充它，那会更惨)， 可是 OOPL 把它做进语言里面去， 那些莫名其妙又诡异到不行的写法就不会出现在你眼前。 另一个例子， 拿以前的 reference counting 实作来讲好了， 这会有一小块东西绑在实际 data 前面， malloc 的时候 size 必须是 sizeof(info type) + sizeof(data type)， 所以你要另外写一个 macro or function， 去把 malloc 来的东西 cast 成 (info *) 再 + 1 才 return 回去， 於是乎 programmer 可以把这 pointer 用得跟平常 malloc 来的一样， 只有 allocate 跟 deallocate 的时候不同， 但是所谓的「乱搞」问题也因而产生， 他可以不照规矩直接 call free() 去 deallocate。 用 C++ 实作相同功能的东西可以防止这个「乱搞」， 而如果这个功能是为了 garbage collection， 虽然 Java 的原理不是 reference conuting 技术， 但是 Java 已经内建在语言， 所以更不可能乱搞。 比 reference counting 还千奇百怪的 code 到处都是， 所以我要强掉的：「C + 一堆 tricks」 == 「C++ + 很少 tricks 」 就是这个原因。 一个 C project 里面通常会有一两个超强的 C programmer， 他们写的神奇东西可能因为其他人太烂所以被「乱搞」， 但是这些神奇东西在 C++ 直接被做进语言或标准函式库， 其他人就算再烂也至少「有书可翻」， 被乱搞的机率大幅下降 (我想你应该知道我已经排除不读书的人)， 而且出问题的时候， 也因为底层的东西是「标准的」， 所以你不可能需要 trace 到里面去， 但是 C 就需要， 至少 reference counting API 在 C 不是标准的东西， 你不可能不怀疑里面有东西写错。 > 比 C 高阶的东西用途都是受限的, 这就是为何 C++ 反而萎缩被 java, C# 吃掉 C++ 从来都没有盛行过， 而 Java 和 C# 盛行是因为现在电脑都太好了， 跑慢一点 user 也没差， 加上都是大厂在推， 尤其是 Sun 还到处帮人家的 OS 写 VM， 所以编出来的执行档 (为跟 C++ 比较姑且这麽称呼) 可以直接拿去别家 OS 执行。 C++ 拼不过 Java 和 C# 市场还有一大原因， Java 提供广泛的 API， C# 提供了功能强大的 .NET framework， 这些东西几乎都是预设就有， 而且哪个平台都能用 (.NET 在这方面跟 Java 相比倒是比较弱势)， 但是 C++ 在那边拼死命的坚持「语言标准与平台无关」， 连 thread lib 要进 C++ 都被挡了快 10 年 (其实不看标准制订日期的话早超过了)， 像是 socket lib 这种东西更是不用讲了， 可惜现实上是现成元件越多的语言越受大家喜爱， 就是如此而已。 你在用传统 C++ 搭 MFC 写 MS 视窗程式， 人家开 Java 和 C# 的 IDE 跟你拉元件拉得很高兴， 某些人因此改用 BCB 去跟他们拼了， 但是人家写出来的东西可以拿去其它机器直接跑， 连手机上跟 PDA 都可以， 就是你的不行， 不会因此跳槽去 Java 跟 C# 的人可说是少之又少， 至少写 application 的都会跳过去， 学商的都知道 Java 跟 C# 的这些好处可以省成本， 大幅招募会 Java 和 C# 的人来当员工， 整个市场一炒作下来 C++ 当然连爬起来都没机会就被淹了。 > 还会出来拔掉一堆东西的 embedded C++ Embedded C++ 这东西顾名思义， 是给 embedded system 用的， 事实上这个东西是假设 C++ programmer 都很无知， 要不就是制订 Embedded C++ 的人对 C++ 并不了解， 我上面列出的 commercial C/C++ compilers 有些会支援 Embedded C++， 但是值得注意的一件事情是， 它们允许你选择打开 Embedded C++ 里被 disable 的 C++ 功能， 为什麽 commercial C++ compilers 会干这种事情？ 这正是因为 Embedded C++ 有很多失当的地方所致， 正常的 C++ programmers 不愿意接受这些白痴的限制。 > 要比省打字工, 4GL 更省, 要做 data structure, pascal, java, c# 也可以 > 要效能, 大家都乖乖用 C+asm 写的 library 去了 选 tool 不单是看省打字工跟 performance， 容易 maintain 和 debug 的才是好 tool， 实际上 C++ 的 layout 非常明确， 并不会像你说的那样， 除非你用上了多重继承。 既然你举了 embedded c++ 的例子， 那我顺便提一下， 以前大家都认为 embedded system 用 C + ASM 就很棒了， 要跨平台的弹性也有 Java 跟 C# 可以撑， 怎麽会有那麽多家公司想做 for embedded system 的 C++ compiler？ 这当然是有它的需求存在， 你前面说要省打字工可以选一堆 language， 要效能可以选 C + ASM， 那如果两个都要呢？ C++ 就是答案之一。 C++ 在 performance 上的问题没你想的夸张， 甚至是 memory 的占用上； 就算是使用纯 OOP 撰写程式也不会比 C 差到 10% 以上， 擅长使用 template + OO 的人可以降到 1.5 - 3% 左右， 而且 memory space 也不会因为使用 template 占用太多； 使用 template 来搭 OO 可以压低继承树增加 performance， 甚至是将 runtime 的 recursive call 改写成一连串相异函式的 tail-call， 懂得如何帮 template 瘦身的人更不会因为 template 而让程式特别吃记忆体， 这些都有书可以学。 > C 连 calling convention 都标准化, 跨 compiler 的 linking 都可以, > C++ 原来 function name encoding 还算有标准, 现在不同家的 obj file 无法互通 事实上 C 那个不是标准化， 只是 x86 上有特别订一套而已， 你去别的 architectrue 上 try 也是死成一片， 除非 architecture 的制作官方有订出来 (像是 ARM 有订 APCS，後来还有改版)， 不然都是一样互相 link 通通死光光。 > 更不用说语法捡查都不一样, gcc3->gcc4 一堆东西不能 compile > visual c 5.1->6.0->.net 也是, 更不用说 borland, ibm 只做了半套 template 那不叫语法检查不一样， 我之前不是说过了， 因为 gcc3 用 bison 做的 parser 实在有够烂， gcc4 重写了 parser 实施了正确的检查， 所以 gcc3 会过的 gcc4 才没有办法过。 我也说过 compiler 的开发是渐进式的， 尤其是 parser， 当 C++98 标准出现以前， 大家遵守的是 ARM (不是前面提到的那个 architecture name)， 并随着各种即将进入 C++98 的标准逐步修改， bison 这个 tool 禁不起这种多变性的需求， GCC 到後来才终於整个重写。 如果你真的熟悉 C++ 标准， 你应该知道有很多东西在旧的 compiler 放很松， 以 eMule 的 source code 来说最大的差异就是 typename 的检查， 如果 T<X>::type 的 T 是一个 class template， type 是 T<X> 里面的一个 typedef， 根据 C++ 标准， 你用 T<X>::type 宣告一个变数需要在前面冠上 typename， 但许多旧的 compiler 自行放宽了这个限制， 这个光 VC 6 (C++98 标准制订前发售) -> VC 7.1 就会遇上了， 大学时代我同学把我叫去帮他编， 我就解过一次， 其它软体在 GCC 上也遇到过这个问题。 > C 从来没发生过旧 code 不能 compile, 或 obj file 不能 link 是吗？ 我国 BBS 的 source code 就惨遭以下大地震屠杀： 我手上的环境是 GCC 4.3： > gcc43 -v Using built-in specs. Target: i386-portbld-freebsd6.1 Configured with: ./..//gcc-4.3-20070302/configure --disable-nls --with-system-zlib --with-libiconv-prefix=/usr/local --with-gmp=/usr/local --program-suffix=43 --libdir=/usr/local/lib/gcc-4.3.0 --with-gxx-include-dir=/usr/local/lib/gcc-4.3.0/include/c++/ --infodir=/usr/local/info/gcc43 --disable-libgcj --prefix=/usr/local i386-portbld-freebsd6.1 Thread model: posix gcc version 4.3.0 20070302 测试档： #include <varargs.h> void foo(...) { } int main() { foo(1, 2, 3); return 0; } 错误讯息： In file included from test1.c:1: /usr/include/varargs.h:34:2: #error "<varargs.h> is obsolete with this version of GCC." /usr/include/varargs.h:35:2: #error "Change your code to use <stdarg.h> instead." 如果你说这只是 C standard 改了 library header 又没什麽， 那我把它改成 #include <stdarg.h> 好了 (其实这个例子什麽都不用 #include)， 结果又出现： test2.c:3: error: ISO C requires a named argument before '...' 很遗憾， 这段纯 C 程式码在 15 - 20 年前可以正确无误的通过编译， 连一个警告讯息都不会有， 我从 K&R C 一路玩到 C99， legacy code 会遇上什麽问题都遇过了， 说 C 不会遇到 ARM -> C++98 -> C++03 -> C++0x 的问题， 那是绝对不可能的。 知道 GCC 为什麽会有 -fstrict-aliasing 这个 option 吗？ 因为 C standard 後来有放松一些 aliasing 的判定方式， 让 compiler 能做出更多的 optimization， 以致於有些做过 pointer casting 的老旧 code (GCC 手册的范例是 union)， 在 -O2 以上编译出来的程式码， 在「执行期」发生了与过去完全不同的意外行为。 > 如 linux kernel 还可用各种不同 compiler, 很多平台是没有 gcc 的 照标准写哪怕换了 compiler 就会炸掉？ 更何况那种东西搭一堆 #ifdef 就好了， 如果不是写 linux kernel (cross-compiling)， 那还有 autoconf 可以搭上去用。 问题是很多人不懂标准， 而且标准也会随着时间修改， linux kernel 算还好的， 虽然没有直接重写成 C++， 但是至少 code 跟 implementation 有在改进， 所以我一直都没有把它当成 yacc 来骂。 -- 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-220-241.dynamic.hinet.net ─╨─╨─ ＫＧＢＢＳ ─ ◎ 遨翔"BBS"的狂狷不驯；属於年少的轻狂色彩 ◎