一堆學(xué)術(shù)派閑的蛋疼總搞語法，沒有一點(diǎn)實(shí)用價(jià)值。
就不能加點(diǎn)庫嗎？文件系統(tǒng)，通信，圖形...

你把別人都秒了，別人還敢招呼你？唉，明明3你知道他說的不對(duì)，你也得點(diǎn)頭說好。低調(diào)點(diǎn)，低調(diào)點(diǎn)...

隨便拉出一個(gè)來就能秒天朝的 北*大學(xué)，清*大學(xué)到火星...

很有前途和很有錢途啊。

工作是做網(wǎng)絡(luò)安全？

簡單實(shí)用

厲害

remove函數(shù)并不是真正刪除，而是取代，然后調(diào)析構(gòu)，built-in類型沒有析構(gòu)函數(shù)結(jié)果就發(fā)現(xiàn)只是向前移動(dòng)了一下，僅覆蓋而已。
復(fù)制元素并非就一定不高效，對(duì)于built-in類型，復(fù)制比修改指針高效，畢竟程序設(shè)計(jì)里小對(duì)象比大對(duì)象常見的多。再說了，大對(duì)象哪里有動(dòng)不動(dòng)就拷貝的，那是設(shè)計(jì)失誤。
vector的刪除和插入都建議在尾進(jìn)行，否則效率低下，因此就沒有.pop_front這種貨。

@編程小學(xué)徒
想考哪個(gè)學(xué)校，把往年專業(yè)課題買來看看，專業(yè)課基本就那個(gè)范圍，如果能進(jìn)入復(fù)試，把那個(gè)學(xué)校往年期終考試題目買來看看就能對(duì)付筆試。考研時(shí)通常考完政治，大家都覺不出好壞，考完英語考數(shù)學(xué)時(shí)考場人數(shù)剩下2/3，再考完數(shù)學(xué)考專業(yè)課時(shí)剩下1/3。在高中時(shí)懷著憧憬，等你讀了大學(xué)你會(huì)覺得大學(xué)真是浪費(fèi)青春，讀大學(xué)對(duì)研究生憧憬，等你讀了研究生你會(huì)覺得研究生真是浪費(fèi)青春，但是跨專業(yè)報(bào)考是得到某個(gè)行業(yè)門票的一條途徑。
程序是所有計(jì)算機(jī)課程的實(shí)際體現(xiàn)，但有兩樣最明顯，算法和數(shù)據(jù)結(jié)構(gòu)還有英語。前者是基本功鍛煉縝密的邏輯，后者幫助程序員自學(xué)和解決問題更快。

為了混口飯吃，大家都不容易啊，原諒刷題的同學(xué)吧。話說學(xué)校里能教啥呀，都靠自己用心，有上進(jìn)心才是最重要的，否則筆試面試再好也是白扯。從面試官的角度看考試沒有錯(cuò)，換成我會(huì)找有潛力的或者上進(jìn)心強(qiáng)的。

pool不拼接內(nèi)存，一塊大內(nèi)存被分割成很多相等的小塊，此時(shí)調(diào)用分配一塊較大內(nèi)存可能失敗，不是因?yàn)閮?nèi)存不夠用，而是因?yàn)槿欠指畛尚∷閴K不拼接導(dǎo)致的。這是Pool的致命傷。再者Pool的效率也高不到哪里，以不拼接小塊換速度的做法不值得提倡。

苦海無邊，終于熬出頭了

很難，除非綁架編譯器，否則怎么能很方便的知道指針在棧上還是堆上？

這種對(duì)象指針默認(rèn)轉(zhuǎn)換中類型都丟了，析構(gòu)的時(shí)候調(diào)用哪個(gè)系夠函數(shù)？手工刪除時(shí)就死悄悄，用智能指針當(dāng)然也照樣死悄悄。何止對(duì)象這樣啊，C++里永遠(yuǎn)都是這樣，如果自己想自殺，C++絕對(duì)成全你，這是Human Right!

耗費(fèi)內(nèi)存太多

很好的總結(jié)

@陳梓瀚(vczh)

謝謝。顯卡藍(lán)寶HD5750 GDRR5 1G顯存，中端游戲卡，應(yīng)該沒問題呀。

看來我得查下后臺(tái)看看誰在作怪。

VS2012功能豐富，想干啥都方便了很多。

缺點(diǎn)就是太大了，機(jī)器運(yùn)行起來明顯感覺慢。這微軟弄那么多C#寫的插件塞在里面，狂吃內(nèi)存還拖慢速度，就為快速開發(fā)？我機(jī)器配置E3 1230，8G內(nèi)存雙通道，1T硬盤64M緩存，主板芯片C202，Win7 x64系統(tǒng)，不應(yīng)該是機(jī)器問題，運(yùn)行別的程序飛快呀。

@春秋十二月
做嵌入式。

語法越來越復(fù)雜，太多的人不得不浪費(fèi)太多時(shí)間熟悉那些花哨的東西，工業(yè)語言是這么進(jìn)化的嗎？？C++總會(huì)有一天死在這幫家伙們的手里。。。

加入thread和一些必要的庫也就罷了。弄一堆形式上的寫法無非少敲幾次鍵盤，形式上看起來爽點(diǎn)，沒有任何實(shí)用價(jià)值，感覺C++越來越花哨了。

這棵樹如果自己實(shí)現(xiàn)就加個(gè)父指針，從當(dāng)前節(jié)點(diǎn)向上走到根節(jié)點(diǎn)，這條路沿路節(jié)點(diǎn)做一下標(biāo)記，然后從第2個(gè)節(jié)點(diǎn)向上走，第一次遇到曾經(jīng)標(biāo)記過的節(jié)點(diǎn)就是最近公共祖先，一直走到根節(jié)點(diǎn)都沒遇到就屬于不同的兩棵樹。

這種考試的題目極少有實(shí)用價(jià)值。

有時(shí)間試試gcc的unordered_map吧，注意版本號(hào)4.6.3以后的，4.6.2版本的哈希表比4.6.3的哈希表處理字符竄時(shí)慢的不是一點(diǎn)半點(diǎn)。處理大量字符竄，尤其字符竄很長時(shí)，因該比SGI_STL的哈希表快得多。gcc的哈希表處理整數(shù)可能比SGI_STL的哈希表要慢，主要是Allocator作怪。

@墨魂
Gnome和KDE都是應(yīng)用，Linus Torvalds也在公開場合說過KDE做的很不錯(cuò)，否則在那個(gè)C的世界KDE早死了。

Qt的版本升級(jí)很快，看來很多人在用(如果沒幾個(gè)人用那還有必要頻繁升級(jí)嗎？)再想想Qt商業(yè)應(yīng)用得花錢買版權(quán)，如果Qt跟GTK+比真的那么差，誰愿意花錢買不好的東西呢？用免費(fèi)的GTK+(C)或gtkmm(給C++用)豈不更好？

順便說下zjh貼的那段代碼，我真看不出是C的。C89和C94沒有//的注釋符號(hào)，C99的規(guī)定是何年月啦，微軟的編譯器哪里能升級(jí)那么快？Win2K能趕得上嗎？

@墨魂
Gnome和Xfce都用C，但是速度差別那么大怎么解釋？很多事情跟語言關(guān)系不大對(duì)不對(duì)。再舉個(gè)例子，Chrome，F(xiàn)ireFox，IE都用C++來寫，速度和資源消耗是不是也差別很大？這又怎么解釋？
我再舉個(gè)例子吧，MTL聽說過吧，做計(jì)算的。做數(shù)值計(jì)算，C和C++沒法跟Fortran比速度，同樣的算法，速度得差20%，但是MTL開發(fā)出來后，尤其4.0以后把Fortran都秒飛了，你能說C++不行？那為啥不用C來做，如果C真的那么快？

任何語言都有優(yōu)點(diǎn)和缺點(diǎn)，否則某種語言早就一統(tǒng)江湖了。。。

@zjh
Java寫系統(tǒng)還真有，也不是什么畢業(yè)設(shè)計(jì)。你可以谷歌下JNode，除了一點(diǎn)匯編，其它全是用Java寫的。
至于你說把虛擬機(jī)固化到芯片里，雖然我沒見哪家這么干，但是我確實(shí)聽說有的ARM芯片可以直接執(zhí)行字節(jié)碼。

我們做嵌入式，芯片的計(jì)算能力非常有限，內(nèi)存也跟臺(tái)式機(jī)沒得比，是很在乎資源消耗的。以前一直認(rèn)為C++比C慢很多，耗費(fèi)資源也多，關(guān)于C和C++之間的速度差別查閱了很多資料，評(píng)測過N次，發(fā)現(xiàn)幾乎沒啥差別。

C++的缺點(diǎn)是很明顯的，新手很容易寫出垃圾代碼，速度慢耗費(fèi)內(nèi)存多，但優(yōu)點(diǎn)也很明顯。我們目前做的一個(gè)程序大約2百萬行源代碼，C++代碼大約90%以上，C代碼大約5%，還有1%不到的Lua。如果C++的部分也用C來做，你想想源代碼量會(huì)有多大，維護(hù)起來會(huì)有多痛苦...

@zjh
這里有個(gè)簡要的圖和介紹，我不明白你指代那一部分：
http://en.wikipedia.org/wiki/Architecture_of_Windows_NT

用C++寫操作系統(tǒng)內(nèi)核不是新聞，用Java寫的都有。。。

這里有用什么語言編寫的介紹：
http://www.lextrait.com/vincent/implementations.html
這里也可以查到：
http://www2.research.att.com/~bs/applications.html

就說NT吧，不是微(micro)內(nèi)核，也不是單(monolithic)內(nèi)核，應(yīng)該算Hybrid。你可以搜索到NT架構(gòu)，我也不清楚你說哪一部分。HAL層我估計(jì)應(yīng)該用匯編，據(jù)說這些匯編主要來自一個(gè)祖籍臺(tái)灣人的貢獻(xiàn)(你可以了解一下微軟的歷史，那幾個(gè)技術(shù)鼻祖)。再上面一層(Kernel mode drivers 和 micro kernel)，古老的代碼應(yīng)該是C寫的，后來改寫的代碼是C++的，再上面也是這樣，古老的代碼是C的，后來的是C++的。其實(shí)不僅Windows，Office也是這樣的，最古老的代碼是匯編，后來的用C，C++出現(xiàn)以后所有的新東西都用C++來寫。你不是有win2k代碼嗎，你最好找到我說的那一層看看是不是這樣。

@zjh
建議你谷歌一下吧，或問微軟的架構(gòu)師，感覺這玩意沒啥好爭論的。

@墨魂
如果你還要比，我還能給你舉出更多例子說明C++比C快，耗費(fèi)內(nèi)存也少，如果有人說C++比C快耗費(fèi)內(nèi)存少，我同樣也能舉出很多反面的例子。。。

@墨魂
唉，那個(gè)排名能說明個(gè)啥呀，跟效率沒關(guān)系是不是？
其實(shí)C++和C速度上沒差別，你可以看下struct和class的內(nèi)存布局，內(nèi)存布局都一樣，哪來的速度差別呀。。。
C++唯一慢的地方是虛函數(shù)(C沒有)，需要查虛表，就一兩條指令的開銷帶來的好處是不言而喻的。。。
至于Gnome和KDE，畫面質(zhì)量不同，內(nèi)存和計(jì)算量相差那么大，比速度和內(nèi)存有意思嗎？你咋不拿控制臺(tái)給Metro比速度和內(nèi)存呀。。。
C++是有很多缺點(diǎn)被很多人指責(zé)，編譯慢，語法太復(fù)雜，新手很容易寫出爛代碼。。。這都是真的，但是不恰恰說明很多人在用C++嗎？否則怎么可能發(fā)現(xiàn)這么多問題呢。。。就如同我們天天罵windows一樣，你見過幾個(gè)人罵Linux？沒有幾個(gè)人用，哪里能發(fā)現(xiàn)那么多問題。。。

@zjh
順便給你掃盲一下吧。微軟的所有產(chǎn)品(除了.net框架的一部分基類用了C#)，其余是一色的C++程序，就連C#編譯器都不例外，當(dāng)然了，個(gè)別地方有點(diǎn)Intel匯編。
若干年前Windows Phone上嘗試了一下用C#寫了個(gè)軟鍵盤程序，發(fā)現(xiàn)速度太慢，最終只好又退回到C++。DOS是用匯編寫的，從Win95以后，都是C++代碼外加少量匯編。Win2K的代碼泄漏過一次，不知道現(xiàn)在網(wǎng)上是否還能下載到，是用C++寫的，這個(gè)能看到。

不要覺得WinAPI是些C代碼就認(rèn)為Win內(nèi)核是用C寫的，你可以去問微軟的架構(gòu)師。。。

唉，我說樓上的那位。Win內(nèi)核是用C++寫的，少量Intel匯編，你去問微軟的架構(gòu)師好了，我不解釋。。。

http://www.phoronix.com/scan.php?page=home
這里有很多比較，有硬件的，也有軟件的。
至于你文中提到的C++拋出異常，我真想知道有多大開銷，問題是你拋什么異常，怎么拋異常，怎么處理異常。根據(jù)經(jīng)驗(yàn)，異常處理會(huì)難倒很多C++老手，所以我懷疑你怎么使用異常，會(huì)不會(huì)很好的使用。
C語言穩(wěn)居什么排行榜的事情跟效率有關(guān)嗎？既然C那么好用為何比排名第一呢？你不覺得你那種論斷荒唐嗎？
至于你提到的圖形庫，GTK+和QT，這玩意怎么比呀。作出的圖形不同的畫質(zhì)計(jì)算量會(huì)千差萬別。都是用C寫的界面，GNOME和XFCE速度相差很大，這怎么解釋。即使如此，KDE也未必比Gnome慢哪里去，還在上面那個(gè)鏈接，你自己看。

C語法和用法相對(duì)比較簡單，C++語法和用法相對(duì)復(fù)雜，或者說看你會(huì)不會(huì)用C++罷了。小程序比較快慢沒有意義，上下差不了幾個(gè)毫秒，可以看成誤差。我們還是比個(gè)比較大的程序吧，你覺得最新的Linux系統(tǒng)顯著比最新的Windows快嗎？前者是C寫的，后者是C++寫的。測試了很多項(xiàng)，都是常用的，除了文件讀寫外(EXT4對(duì)NTFS，個(gè)人覺得是格式問題)，其它項(xiàng)Linux全軍覆沒。在Linux一個(gè)網(wǎng)站上比較的Ubantu和Win7，自己谷歌一下吧，我不解釋。

小的容易做到，boundary tags, bitmap, freelist都行，大的需要比較復(fù)雜的數(shù)據(jù)結(jié)構(gòu)，建議用PTrie，你可以參考下DLMalloc，谷歌下。

如果多處理器并行環(huán)境，那就非常困難了，傳統(tǒng)的并發(fā)控制機(jī)制會(huì)成為瓶頸，還要小心False sharing, blowup...，你可以參考下JeMalloc，谷歌下。

不像樓主說的那樣，我們這里女程序員就算占不到1/2，肯定超過1/3

需要用到直接插入排序，堆排序和三點(diǎn)取中找支點(diǎn)，然后分割，有點(diǎn)麻煩，到這里去看怎么優(yōu)化的：
http://m.shnenglu.com/Chipset/archive/2011/08/16/153546.html
或者把STLPort代碼下載下來去里面找，原理是一樣的。
我主頁上有常見的14種排序，如果單線程的話，快排是最快的，多線程需要重新設(shè)計(jì)，太麻煩，最容易實(shí)現(xiàn)并行的排序個(gè)人認(rèn)為是歸并排序。

你的速度不行，數(shù)據(jù)結(jié)構(gòu)書上的更垃圾。

如果你家是東北的，我可以推薦你來我們這邊做嵌入式，不知道你是否有興趣。

@123
啥意思啊，對(duì)天朝沒信心？

@.
猴子排序理論上最壞情況下時(shí)間復(fù)雜度為無窮大，最好情況為O(n)，一般情況為O(n*n!)。可見確實(shí)比我的蝸牛排序慢。

猴子排序偽代碼如下：
while (沒有排好序)
打亂當(dāng)前序列的順序;

很同情博主經(jīng)歷，很佩服博主自強(qiáng)不息的精神。

工資跟當(dāng)?shù)厣钏较嚓P(guān)，跟做的事情相關(guān)，跟周圍環(huán)境或者說公司本身相關(guān)。

估計(jì)你的某句話或某幾句話得罪了某幾個(gè)看客了，以后說話謙虛點(diǎn)，做人低調(diào)點(diǎn)就是了。

唉...

內(nèi)存管理系統(tǒng)的事情，對(duì)C++要求這么高，是不是太過分了。new就是一個(gè)殼，調(diào)了API。當(dāng)然，最好別重載全局new，局部的我看也最好別重載。一般程序new就足矣，多CPU并行和吞吐量的程序，只能自己來管內(nèi)存，否則慢也就罷了，還出一堆碎片。

系統(tǒng)管理內(nèi)存都做不到完美，指望語言級(jí)別依賴于實(shí)現(xiàn)的new能做好？看看系統(tǒng)內(nèi)核每次升級(jí)，有多少改動(dòng)發(fā)生在虛擬內(nèi)存管理器...

Douglas Comer也得罪你啦，講點(diǎn)道理行不？

Linux Kernel也大量用到了動(dòng)態(tài)內(nèi)存分配。既然操作系統(tǒng)內(nèi)核都不怕動(dòng)態(tài)分配內(nèi)存造成碎片，應(yīng)用程序?yàn)槭裁匆ε拢?

暈，什么時(shí)候操作系統(tǒng)都不怕碎片啦？linux內(nèi)核原來用buddy，2.2以后來用slab因?yàn)樯对虬。款愃魄闆r還有FreeBSD5.0， NetBSD4.0和Solaris2.4以后。

__int64是Win的，不是C++的，int64_t是C++新標(biāo)準(zhǔn)才有的，但是新標(biāo)準(zhǔn)還沒下來
long long是C的(C99)，也不是C++的。

可以自定義兩個(gè)32位整數(shù),一個(gè)存高位，一個(gè)存低位，一個(gè)struct結(jié)構(gòu)，就有了64位

看了三篇文章。不知道該說啥好，單CPU，DLMalloc足矣，其它我都不看好，最不看好用完最后一次性釋放的內(nèi)存池，原因不解釋。

多CPU，ptmalloc3，或glib里的內(nèi)存管理器(以ptmalloc3為基礎(chǔ)的改進(jìn))，谷歌的TCMalloc，還有Free BSD的Jemalloc，以及Hoard。多CPU，碎片率低，好的線性加速比是關(guān)鍵，Jemalloc很強(qiáng)。TCMalloc看上去像個(gè)多CPU的自有列表內(nèi)存管理器，加速比也不錯(cuò)，且有垃圾收集，但是啟動(dòng)速度跟啟動(dòng)Java虛擬機(jī)絕對(duì)有一拼...這些都是免費(fèi)的。至于那些要錢的，我懶得一提...