Re: [問題] 為什麼作業系統都用C寫？　而不用C++呢?

看板C_and_CPP作者littleshan (我要加入劍道社!)時間15年前 (2009/03/07 13:38)推噓20(20推 0噓 120→)

留言140則, 7人參與討論串10/37 (看更多)

僅就我能回應的部份回應，畢竟我也沒什麼料。 ※ 引述《guest0079 (火辣辣的大姊姊)》之銘言： : 　一般認為C++效能較差是有幾點現實上的考量： : 　a. C++太多太雜太難掌握，讓程式人員浪費太多時間在語言本身而非問題的最佳解上這和程式的效能無關。如果你要說的是 C++ 的某個語言特性使得實作某些演算法變得很困難，請舉出具體實例，而且你還要證明用 C 實作會比較簡單。 : b. C++會偷偷增加一些程式碼來維持本身的OO特性，一不小心就多出了不必要的code : c. C++會偷偷增加一些程式碼來維持運算子過載特性，一不小心就多出了不必要的code 同上，請就這兩點舉出具體實例並證明同樣的功能在 C 中並不會造成額外負擔。 : 　d. 用C++物件導向實作的函式庫，很方便使用沒錯，但代價就是負擔太大(如Qt) 所以負擔是什麼？同樣的功能用 C 實作可以快多少？ : e. ...應該還有很多我不知道的 : 2.C++程式不易讀 : 運算子過載真是太好用了，而且程式一看就懂，真是太好維護了，但是如果… : 　 Man a_man("大雄"); // 定義一個男人 : 　 Woman a_woman("靜香"); // 定義一個女人 : int money = MAX_VALUE; : 　 printf("幹這是什麼鬼：%s", a_man + money + a_woman); : 　這種code要怎麼維護？先回頭找一下Man與Woman中operator + 的定義 : 　再確認與int作運算表示什麼，再查一下書看看運算的順序的先後關係，如果operator : 　中又用到其他operator的過載，又要再去查，為了追一個問題，又引起n個問題，為 : 　了確認n個問題，又出現n^2個問題…沒完沒了。程式很簡潔沒錯，但是要怎麼debug？ : 　難道每一行程式都要猜猜看嗎？所以改用 C 的寫法是像這樣囉？ printf("幹這是什麼鬼：%s", Add_Something_Woman( Add_Man_Int(a_man, money), a_woman) ); 也不是不行啦，只是有天你發現 int 不夠用要改成 long 的時候，麻煩就很大了。而且你一樣也是要去看 Add_xxxx 這些 function 的內容才知道他們做了什麼事，而且這些 function 也會用到其它 function，debug 起來並不會比較簡單。另外你自己也說了，「運算子過載真是太好用了，而且程式一看就懂」。這意味著如果你會寫出自己看不懂的 code，那你就不該用 operator overloading。你可能會說，這是某個「自以為很厲害的人」寫出的 code，你不得不用，那可能是以下的情況： 1. 大家都看不懂，只有「自以為很厲害的人」看得懂 code。這種情況當然是「自以為很厲害的人」該死。 2. 一半的人看得懂，另外一半看不懂。請你們在下次技術團隊會議時好好討論要不要改做法。 3. 大家都看得懂，你看不懂。很不幸的，這種情況下是你該多念點書。 : 好的物件導向遠比C好維護，不過C++決對不是好的物件導向語言(這句話一言難盡) : 3.物件導向不適合底層程式 : 了解物件導向的人就知道，它是較貼進人類思維的程式寫作方法，反之，它就不是 : 　一個貼近底層機器運作原理的編程原則，機器語言、組語才是最貼近底層運作機制的 : 　語言，想要用OO來描述機器的行為、自然法則、各式各樣的protocol…等等諸如此類 : 　的運作機制容易流於天馬行空，任意妄為。如果硬要用物件導向來實作底層機制，可 : 　能十個人有十二種不同的見解，沒人看得懂彼此的程式，因為每個人對機制的感受都 : 　不一樣，物件結構的分析各有各的看法，沒完沒了。 : 　當然，不用物件導向也是可以寫C++程式，但那還不如用C來的單純 : 　(但個人偏愛用完全無繼承機制的物件架構來寫C++，來當作是C的加強版) 就我的認知，物件導向的目的並不是要貼近人類的思維，而是為了軟體易於維護並擴充功能。所以如果對一個系統該如何設計，若是每個程式設計師都有自己的意見，那當然是坐下來好好討論哪一個做法比較容易維護、擴充。當然，程式設計師意見不合是常有的事，但並不如你所想象的那樣是天馬行空的爭論，而是而實際地考慮各種設計在維護及擴充上的優劣。 : 4.C++的複雜度太高 : 　C公認的聖經只有一本，內文也才兩佰多頁，一本C++的入門書就一仟多頁(C++ Primer) : C++的功能及其運作細節多如牛毛，寫了10年的程式也許還會看到自已不懂的語法，或是 : debug時發現某個平常不會注意的細節在作怪，這如果只是開發一般的AP還好，如果是開 : 發OS這種大型、不易物件化的程式時，事情就大條了。因為： : a.開發人員太多，每人都用一種冷門的技巧，那要trace code就要買十本C++在身邊才行 : b.總有人喜歡賣弄技巧，喜歡來個多重繼承，自行定義運算子，把程式的複雜度弄得很高 : 　自以為很強，等到程式成長到自已無法控制(可能久了也忘了)才雙手一攤說：比爾蓋茲 : 　對不起，我要去Google上班了 : c.自已乖一點不要寫出太複雜的程式就好了嗎？不！因為C++支援太多種技巧、style， : 　所以有時候不得不乖乖配合別人的程式風格，想維持單一模組風格的一致性也很因難 : OS不是少數幾個人就能寫出來的程式，一定要有不少人力來大量的分工才能完成 : ，但高度的分工之後又必需維持緊密的偶合關係，是一項複雜度很高，極易失敗的專案 : ，如果再用一個複雜度相對較高的C++工具來寫的話，就難上加難了團隊開發本來就應該要先統一好 coding style，此外像是類別應該要有什麼行為、提供哪些 method、哪些東西使用 template，則是在設計階段就應該訂好，如果有某個程式設計師喜歡搞怪不合作，那換用 C 他還是可以完全不合作。為了避免使用者濫用，程式語言不應該提供太多複雜的功能嗎？那 C 應該先把指標拿掉。 #define 也應該要拿掉，不然有人會寫出下面這種東西： #define begin { #define end } : 最後，我很好奇某人說：C++的sort大勝C的qsort，理由何在？ qsort 每次對元素進行比較的時候，都要透過 function pointer 去呼叫 compare function。如果你學過 computer architecture 就會了解，使用 function pointer 會比一般的 function call 還慢，尤其 function 的內容很短的時候，這個額外的負擔就占了很大的比例。因為 C++ 的 sort 是 function template，是在 compile time 就把靜態的 function call 插進 sort 裡面，而且若 compare function 很短，還可以得到 inline 的好處，進一步省掉 function call 的成本，當然會比 C 的 qsort 快上不少。 -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 59.121.115.112 ※ 編輯: littleshan 來自: 59.121.115.112 (03/07 13:40) ※ 編輯: littleshan 來自: 59.121.115.112 (03/07 13:41)

推

guest0079

03/07 15:18, , 1^F

03/07 15:18, 1^F

推

Ebergies

03/07 15:21, , 2^F

03/07 15:21, 2^F

→

Ebergies

03/07 15:21, , 3^F

03/07 15:21, 3^F