※ 引述《[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