※ 引述《tinlans ( )》之銘言：
: 而軟體系統的規模日益增大，
: 8 萬行內的小型軟體系統用這種方法寫還說得過去，
: 70 萬行以上的軟體系統這樣搞還是難逃一劫。
這就是目標差異了。我做的程式主要都是一萬行以下的核心系統，
不用管雜七雜八的客戶需求變動，除非需求變動超過核心系統所能
支援的範圍。
一般都是客戶開一個規格出來，我做出一個超出客戶規格所需要的
通用模組、元件、服務或是虛擬機器、平台、解譯器之類的東西，
其他就由別人處理。基本上我認為 programmer 做到這樣的地步，
也差不多夠了，追求超大型專案製作未必有意義，因為那樣就會有
太多腦殘需求要處理，實在是很浪費生命。
就這樣的方法來看，我不認為世上那麼多百萬行的系統，真的都是
需要那麼多行的程式碼，真的需要那麼多複雜的設計。
至於過去超過十萬行的程式，我還沒試過不用 C++ 的，第一次接
大型專案就剛好遇上 Turbo C++ 1.0 問世，若是不考慮我現在的
軟體開發方法，基本上我可以說大致同意你的觀點。
: 上述做法存在著新的問題，
: 就是 object 之間互相 assign 的機制必須手工製作，
: bitwise copy 並非永遠適當的方法，
: 所以你絕對不可能單靠一個 memcpy 就搞定，
: object 與 object 間的 copy 語義實現，
: 仍是一個繁瑣的任務。
這就牽涉到 object tree 的問題了，實際上 class, data, function 的
組合是不夠的，至少還要加上 object, 在建立一個新物件之時，還要同時
建立其從屬的子物件，一個 object 實質上會是四種 pointer 的組合。
所以最好是能建立一個完整的 object handler 機制才行。包括 class,
object, data, function 都由這個 object handler 來處理。
特別是建立 object tree 結構，同時也解決 GC 問題，在一個物件消滅時，
所有從屬物件也會跟著消滅。
這樣子就不再需要手工製作 object 的 assignment, 大致上只有少數不是
子物件複製的特例需要處理，這在 C++ 當中也一樣要特別做處理，而且有
許多額外的彈性機制存在。因為一個物件的從屬物件是可以不固定的。
比較現實而言，用 C 而不用 C++, 要嘛是建立簡單的結構，要嘛就是建立
超越 C++ 內建機制的複雜機制，只是這兩種狀況，在核心系統製作時，都
可能出現。
其實 C++ 在物件導向上，所實現的動態機制是相當有限的，一些原本使用
smalltalk 的朋友，在轉向商業軟體開發時，往往第一個選擇，就是用 C
實作物件導向，而不是採用 C++.
在這個意義下，是很可以用 C 完成更加完整的物件導向機制的。只是往往
沒有必要，我能做也想過，但始終沒下手去做。
: 你每增加一個 subclass，
: 就得重新實作一次新的 assignment operation。
: 還不只拿是 object_assign_class4(&object3, &object4);，
: 來取代 object3 = object4; 這麼簡單而已，
: 萬一你用 by value 把整個 object 當 function argument 丟，
: 你還得手動 copy 一個暫時物件出來丟，
: 不然你就得規定所有 programmer 在接 object parameters 時，
: 要記得把它們先 copy 一份。
這用 object handler 還可以完成更複雜的事。
我們可以傳 object id, 在取得 object content 時才決定是否複製物件。
這樣也可以大幅度減少拿物件作參數時的複製負擔，在需要時才複製物件。
: 的確，現在的 C programmer 為了在被強迫用 C 的環境生存下去，
: 多奇怪的工具和方法都能搞得出來，
: 說真的已經見怪不怪了。
這不算什麼強迫吧，本來 C 就是這樣的一個東西，在 C++ 出現之前已經
是這個樣子了，而 C++ 本身一開始也是以 C with classes 的面貌，並且
是以 preprocessor 的形式出現。
: 只不過，
: debug mode 的 error message 該如何實作又是一門學問，
: 否則也只是在考驗 programmer 的記憶力罷了，
: 而且將系統交接給別人時，
: 別人不見得有辦法理解這些 messages 的意思。
這的確都是學問呢。
: debugger 還有不少超乎想像的能力，
: 像是用 watchpoint 去抓有問題的 pointer accessing，
: 或是當程式因為某因素掉入 infinite loop 時，
: debugger 可以直接攔截下來看程式的狀態，
: 能省下不少時間成本。
這些情況都應該事先避免的，例如很多人都會實作 pointer table,
傳值時不直接使用 pointer, 而是 pointer id, 然後在取值時自動
檢查，並在 debug mode 時則顯示發生錯誤的位置，更嚴謹一點的，
還同時檢查資料型別。
當然, pointer table 建置及資料型別編碼又是一個學問。
: 新人 training 的時間成本不一樣。
: 首先，因為 C++ 已經統整了 OO syntax 標準，
: 你就算能把 myclass class2; 和 sub_class() 那段用 macro 合成一行好了，
: 問題就是沒個標準，
: 現在 A 公司跟你來個 INIT_CLASS2() 的 macro，
: 然後 B 公司跟你來個 CREATE_CLASS2() 的 macro，
: 當然我相信你也知道差異不會這麼單純而已，
: 員工從 A 公司跳到 B 公司去，
: 整個機制幾乎需要整個重新 training，
: 而不能假設他在學校學過 C 的 OO 寫法就能馬上 default 他懂。
現在會使用 C 的情況，主要都是跟系統相關或核心功能的部分了，大概不會有人
叫新人來做的...
而即使是用 C++, 這個情況也沒有好到哪裡去，號稱會 C++ 的有幾個真的會了?
只會用不會改 iostream, 幾乎完全不會用 STL 的，只怕佔了大半，而若要用個
boost 大概連人都徵不到，這還是個即將成為標準的程式庫呢，還不是都要從頭
訓練。
以現在的資訊教育狀況，找個在學校裡改過 bbs code 的就算中上了，從學校教
出來的，理論或許沒有全還給老師，但寫個三百行程式練習就躲回家不來上班的
大有人在。真是不指望了。
程度夠的人教什麼都快，不懂的就慢慢熬吧，標準問題的差別沒有想像中大。
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 61.222.173.26