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

[guest0079 (火辣辣的大姊姊)]

這串討論似乎變成C與C++之爭
最精采的是看到yehsd、yoco315(按字母順序排序)兩人的激烈攻防
這串討論我反覆地看過兩次，再上google參考前人對C/C++的見解
比對之下，個人覺得yehsd、yoco315兩位的論點太虛了，不著邊際，搔不到癢處
兩位可能都是一等一的高手，程式底子十分深厚，但是兩位的言論流於意氣之爭
幾乎沒什麼重點可言
討論什麼constructor是不是空的實在是很無聊，就算是空的又如何？

我個人比較傾向於認為：C++不適合用來寫OS，用C寫才是王道
但yehsd似乎也提不出多棒的觀點來證明C++的不好
以下是我向yoco315提出「用C++不適合寫OS」的理由

1.效能也許會較差(這一點兩位y兄爭了很久)：
　說真的，我完全不能證明C++比C效能還差，甚至我可以證明，C效能永遠不比C++好
　證明如下：
　若set_Y為C中效能優於C++的子集合，已知C++為C的超集，set_Y必然也是C++的子集
　set_Y at C > set_Y at C++，固set_Y為空集合
　總之，C做得到的C++也做得到，C++的效能沒理由較差
　一般認為C++效能較差是有幾點現實上的考量：
　a. C++太多太雜太難掌握，讓程式人員浪費太多時間在語言本身而非問題的最佳解上
  b. C++會偷偷增加一些程式碼來維持本身的OO特性，一不小心就多出了不必要的code
  c. C++會偷偷增加一些程式碼來維持運算子過載特性，一不小心就多出了不必要的code
　d. 用C++物件導向實作的函式庫，很方便使用沒錯，但代價就是負擔太大(如Qt)
  e. ...應該還有很多我不知道的

2.C++程式不易讀
　C++遠比C複雜太多了，太多好用的功能疊加在一起就變得很難用
　例如：運算子過載(重載?)
　      Integer a = 1; // a為1
        Integer b = 3; // b為2
        printf("a+b=%d", a+b); //印出3
  運算子過載真是太好用了，而且程式一看就懂，真是太好維護了，但是如果…
　      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好維護，不過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++工具來寫的話，就難上加難了

最後，我很好奇某人說：C++的sort大勝C的qsort，理由何在？
※ 引述《yoco315 (眠月)》之銘言：
: ※ 引述《yehsd (急)》之銘言：
: : [再次感謝版友 adrianshum 提醒, 我應該說的詳細點]
: : 和這句, 有沒有矛盾點?
: : [我想說的是, ctor 是空的, 還是會有 default ctor, 這點如同 adrianshum
: :  所言. 如果在 instantiation 時指定了自訂的 ctor, compiler 就不會去 generate
: :  default ctor. 所以 littleshan 所說的: constructor 是 compiler 幫你自動
: :  呼叫的指的應該是 default ctor? 因為這個 ctor 才是 compiler 會自動呼叫的,
: :  希望我沒誤解 littleshan 所說的 ^^]
: 我覺得你這個人不錯，
: 雖然不太懂 C++，但是會唸書，也會想，以後會很強。
: 我覺得你不錯，
: 所以我現在願意花時間打字講些很基本的東西給你看，
: 首先，一「空的」函數，在經過最佳化以後是不會被呼叫的，
: 不管他是你自己手寫的，還是編譯器自動生成的都一樣，
: 這是非常基本非常常見非常簡單的最佳化，
: 也就是說你所謂那一百萬次的函數呼叫成本其實不存在。
: : 這是 C++的優點, 但是也有可能是雙面刃.
: 你不能這樣說話的，
: 你得告訴我另外一面是什麼？
: 不然這個句型太強大了，什麼都能套下去，
: 我可以說「C 的不用初始化是一個雙面刃」，或說「C 的速度是一個雙面刃」，
: 但是我不跟你講原因，你會不會覺得我很笑？
: C++ 出來的早，只是「建議你」初始化，
: 現在新出來的語言，幾乎都強迫你一定要初始化，
: 你看，C++ 很卑微的。
: : 看到這邊, 我只能說我可能真的沒你那麼懂 C++, 小弟不才,
: : 用 C++ 開發一個比 C 寫出來還快的OS, 這個重責大任就交給比較懂的人囉.
: 現在懂的不多沒關係，你可以再多念一點，
: 如果你 CPPPL 真的念得很透的話，應該不會講出上面那些話，
: 使戳使挫在書裡面對 C++ 的效能提到很多了。
: 最後是跟程式無關的……
: 自己書看不夠的時候，盡量少叫別人看書，感覺不太好，你知道我的意思。
: 一個人有料的時候，自己可能不會知道。
: 但是一個人沒料的時候，旁邊的人都看得很清楚。

--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 220.136.212.64
推 milo9:老闆 雞排一份(拉板凳)...code size和memory沒有人提一下
→ xam:證明1就證錯方向了..沒抓到重點.. end
推 zerodevil:『一個人沒料的時候... (下略)』
推 Fenikso:所以說寫成add(a_man, money)就不用往前翻找定義是吧..
→ Fenikso:難維護是人的問題 扯到c++幹什麼
→ soma:我也不知道理由何在 但似乎有很多人測試過
→ soma:http://theory.stanford.edu/~amitp/rants/c++-vs-c/
→ guest0079:感謝樓上，文中提到 STL's sort ran faster than C's
→ guest0079:qsort, because C++'s templates generate optimized
→ guest0079:code for a particular data type...
→ guest0079:所以C++較快是因編譯器作最佳化或是語言本身提供的好處
→ guest0079:C不做最佳化是因為語言本身的限制嗎？
→ weiyucsie:可能一樣要配合macro來寫吧XD
→ weiyucsie:不過剛剛想到簡單的實作 code可能會像是inline一樣重複
→ weiyucsie:感覺至少c++可以內嵌sort中比較的部份(可能比較簡單)
推 suhorng:嗯，而C的qsort則是每次比較都有函式呼叫，輸就輸在這裡
→ suhorng:我不知道qsort有沒有結合insertion sort，不過sort有
→ suhorng:只是... 有必要用C++寫作業系統嗎... 如果不必要用到OO的
→ suhorng:高階特性，應該不需要用到C++ ?
推 Chevelle:答案大家都知道 只是大家信的教不同而已..
推 yoco315:我想轉 joke
你這句話的句型太強大了
推 StubbornLin:c語言要寫出看不懂的程式碼也不難 使用者濫用
→ StubbornLin:、惡搞 總不能全怪到語言頭上吧= =|
→ StubbornLin:你如果要說難懂 去看看template寫的meta programming
→ StubbornLin:之類的
→ StubbornLin:還有C做得到C++也做得到 沒理由C++效率比較差這證明..
→ StubbornLin:聽起來就好像 你會吃飯 我也會吃飯 沒理由我的薪水
→ StubbornLin:比你低是一樣的= =|
1.你說的沒錯，使用者濫用，不能怪到語言頭上，但是如果語言提供一推方法讓人濫用
  要要怪到語言頭上，版上的眾高手不會濫用語言，所以不會覺得C++不好，我可以理解
2.C++讓人看不懂，是指沒辦法像C一樣用瞄的就可以知道在寫什麼，C++存在太多種可能
　性，當維護要trace code時就顯得麻煩
3.我也知道編譯器的好壞、編譯選項、目標平台的instruction set、library的實作方式
　…等等都會影響程式的效能，不過我必須強調，本文主要講的是語言本身的特性，而非
　強調C與C++的編譯器及編譯環境，我也知道這才是效能好壞的重點，不過我還是要把
　我的命題鎖定在語言本身的特性上，我文中也都是以這個命題在討論
※ 編輯: guest0079       來自: 220.136.212.64       (03/07 12:05)
推 yoco315:老實說你講的都是十年前早就在newgroup上面被打爆的論點
→ yoco315:十幾年前的java就是用這些說嘴,後來都自己打嘴了 :X
→ yoco315:我沒有不禮貌的意思，你跟y能寫出這些東西都不錯
→ yoco315:只是這些論點實在過時到讓人覺得懷念
推 Fenikso:所以說c++不適合寫os的理由是programmer太笨不會用c++
→ alishas:用沒OO的語言來實作物件導向負擔不是更大...
推 buganini:呃 要怪就全部怪在compiler頭上就好了 所有的程式語言
→ buganini:都是turing equivalent 極限最佳化結果應該都一樣
→ buganini:所以都是compiler不好 *flee*
→ tinlans:這什麼啊？我寫了 13 年 C++ 你講出來的我都沒遇過。
推 Ebergies:這篇明明很中肯
推 H45:看到 OO 我整個火都起來了
推 Bencrie:GTK用得很開心啊 XD
推 alishas:可惜使用者用的不開心
→ alishas:http://gtk-comment.blogspot.com/2008/05/gtkgobject-cc.
→ alishas:html
推 amozartea:只認同3, 1,2,4都是人的問題 不是語言的問題