常見的 C++ 錯誤觀點

看板C_and_CPP (C/C++)作者 (眠月)時間16年前 (2009/03/08 17:11), 編輯推噓5(5011)
留言16則, 9人參與, 最新討論串1/4 (看更多)
我也跳下來玩,不過我 C++ 很弱,請打小力一點 <(_ _)> 1. 效能比 C 差 這個最常見的理由就是「C++ 一定會塞很多你不知道的東西在裡面」 我只能說「不知道的東西也敢講得這麼肯定,不簡單。你不知道,我可是都很知道。」 有的人會拿出這個說法,大概是看了台灣坊間十年前的爛書, 事實上在十年前的 Inside C++ Object Model(我看這本的時候還沒中文版)就講了, 「你不需要付出你不需要付出的代價」當一個東西你沒有用到,C++ 就不會 charge 你。 當 C++ 你只用跟 C 同等語法功能的時候,run time overhead 最多 5%。 當你需要 OO,exception,template 等功能的時候, 你用 C 語言實作這些功能,最多也只能跟 C++ 一樣快, 一般狀況是更慢,而且你要實作到一樣快,你的 C 得受過相當訓練。 (更別說大部分的人連 C 要怎麼實作 OO 跟 exception 都不知道了) 現在那 5% 也幾乎不見了, 事實上,現在 C++ 普遍可以作到比 C 更好的效能, std::sort() 狂電 qsort() 三倍是十年前就知道的東西, 一般容器的效能 C++ 也比 C 好 40%。 C 用 function pointer 的地方很多都可以用 C++ functor 來作到數倍的效能提昇。 這是 C 永遠作不到的最佳化。 「效能差」是 C 擁護者在十多年前的說詞了, 老實說多看看 news group,會發現現在已經沒人講這個了, 拜託不要再拿出來講了,這點真的是解釋太多次多到我都想睡了 orz (附帶提一下,現在要打 C++ 頂多就是講太 expert friendly) 2. C++程式不易讀 這是十年前 Java 用來打 C++ 的論點, Java 當初真的喊很大聲,讓我們複習一下 Java 當初講了什麼: 我們不支援 operator overloading,因為你不能保證使用者不會亂用, 誰知道他幫 Integer 實作的 operator + 裡面是不是減法呢? 是不是很好笑?講得好像 Java 的 compiler 會檢查出下面這種東西然後OB擋掉一樣 class Integer { int value = 0 ; Integer add ( rhs ) { Integer result = new Integer(this) ; result.value -= rhs.value ; } } 不好意思,不會擋掉,編譯器會很開心把他編出來。 看到沒有?只要舉的例子夠奇怪,你什麼都能證明,開玩笑的, 是不管你用什麼語言,你都沒辦法阻止腦殘的程式設計師幹出蠢事, 而且 d = ( a + b ) * ( c + d ) 就是比 d = a.add(b).mul(c.add(d)) 好讀, 這點不是我自己在講的,有個極端反對 operator overloading 的語言也贊成我, 怎麼說?因為 Java 下一版也要內建 BigNumber 的 operator overloading 了 ~_~" 連抱持這個觀點到極限的 Java 都棄守了,C# 也早就不鳥 Java 那套說詞了。 所以不要再自己用手打一堆自己平常寫程式都不可能寫出的爛 code 來當作例子, 舉那些例子唯一能證明的就是舉例的人自己會寫出這麼爛的 code,不是別人。 讓我這樣說吧:的 C++ 可能不好讀,別人的可不是。 3. 物件導向不適合底層程式(或是沒辦法跟底層銜接) 那個問 ASM 跟 C++ 接合的,你不會不代表沒辦法,Google 一下就有答案, link 找不到東西那是因為 C++ 為了 overloading 會作 decorated name, 不知道 decorated name 就去 google,不想看英文的, 可以去 bs2 program 版搜標題「使用 dll 問題??」。 而且幸運的事 C++ 不是純物件導向語言。 當你發現某個地方適合 procedual paradigm 的時候,就用 procedual paradigm, 當你覺得某種型態適合 generic paradigm 的時候,就用 generic paragigm, 當你覺得某個架構適合 Object based paradigm 的時候,just do it! 沒人有人強迫你用 C++ 的時候一定要用 Ojbect Oriented paradigm。 (Java 才有這樣的強迫症:P) 以上幾種設計典型又沒有衝突,一個大型程式一定會每一種都用到。 (如果你知道怎麼用的話,一定每種都會用到, 如果有人只會 procedual,那趕快多學一點) 4. C++ 的複雜度太高 只有這點是真的, 所以請大家不要學 C++,去學 Python 或是 Ruby。 Python 多美好阿,我現在幾乎都寫 Python 了呢 ="= -- To iterate is human, to recurse is divine. 遞迴只應天上有, 凡人該當用迴圈.   L. Peter Deutsch -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 118.160.105.151

03/08 17:17, , 1F
推第4點,前面一大串討論,沒幾篇看得懂
03/08 17:17, 1F

03/08 17:23, , 2F
其實我們做 compiler 的最怕的是 user 自己寫的 code,因
03/08 17:23, 2F

03/08 17:23, , 3F
為猜不出哪些能最佳化哪些不行;同樣的功能 C 是人寫的,
03/08 17:23, 3F

03/08 17:24, , 4F
C++ 是 compiler 幫你生的,compiler 當然很清楚自己生的
03/08 17:24, 4F

03/08 17:24, , 5F
code 是要做什麼,自然也知道那些自己生出來的東西能不能
03/08 17:24, 5F

03/08 17:24, , 6F
合併或砍掉。
03/08 17:24, 6F

03/08 17:25, , 7F
所以我反而無法理解那些強調用 C 寫效能會好的論點。
03/08 17:25, 7F

03/08 17:30, , 8F
關於 4.,我現在是常用 SWIG 把 C++ 接到其它語言去 XD
03/08 17:30, 8F

03/08 19:21, , 9F
推python~~
03/08 19:21, 9F

03/08 19:35, , 10F
python讚
03/08 19:35, 10F

03/08 19:49, , 11F
Py_Initialize(); // XD
03/08 19:49, 11F

03/08 20:39, , 12F
Python推 不過這邊是C_AND_CPP版 呵呵呵
03/08 20:39, 12F

03/08 23:39, , 13F
"再優雅的程式語言也不能阻止programmer寫出爛程式"
03/08 23:39, 13F

03/08 23:41, , 14F
忘記是在哪裡看到的了.....
03/08 23:41, 14F

03/09 12:49, , 15F
我要推Ruby qq
03/09 12:49, 15F

03/09 21:57, , 16F
推一下有口皆碑
03/09 21:57, 16F
文章代碼(AID): #19iulI4r (C_and_CPP)
討論串 (同標題文章)
文章代碼(AID): #19iulI4r (C_and_CPP)