僅就我能回應的部份回應，畢竟我也沒什麼料。 ※ 引述《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)