Re: [討論] 念完資工之後...

看板CSSE (電腦科學及軟體工程)作者semop (semop)時間18年前 (2007/01/05 03:23)推噓0(0推 0噓 0→)

留言0則, 0人參與討論串10/18 (看更多)

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