STL的代碼并不優(yōu)雅，缺乏functional programming機(jī)制支持的C++對(duì)于實(shí)現(xiàn)algorithm非常的牽強(qiáng)，比方我要find(v.begin(), v.end(), compare);的時(shí)候(v是一個(gè)自定義的結(jié)構(gòu))，我必須在函數(shù)外面寫一個(gè)比較函數(shù)，如果要帶一些上下文的話還得寫一個(gè)functor類，非常的丑陋不堪，實(shí)用性大打折扣。而FP系的語言來說，可以非常自然的寫一個(gè)匿名函數(shù)。STL里所標(biāo)榜的容器，算法等概念，在FP里早就原生支持了，而且要優(yōu)雅的多。至于NT代碼這個(gè)我沒看過不好說，但是據(jù)說代碼里有不少當(dāng)初程序員留下來的抱怨BUG及設(shè)計(jì)失誤的話。
>> 內(nèi)存管理是程序設(shè)計(jì)中最經(jīng)典的話題。GC無疑是內(nèi)存管理一個(gè)偉大的變革，但是我只是把它看作內(nèi)存管理的一個(gè)解決方案，而認(rèn)為不是的解決方案。比GC更加優(yōu)雅的方案不見得沒有。我比較傾向于在特定的情況下選擇合適的內(nèi)存管理方案，而不是沒有任何選擇的余地，而這正是C/C++的偉大之處。 所有那些GC語言(如Java、C#等)均把這個(gè)解決方案強(qiáng)加給程序員，這一定程度上來說減輕了程序員的負(fù)擔(dān)，但是也同時(shí)約束了程序員的主觀能動(dòng)性。"分配內(nèi)存和釋放內(nèi)存在C語言中都是很慢的"?不知道作者從哪里獲得的結(jié)論。
實(shí)話說我也不喜歡GC，沒有GC的C也可以工作的很好，但是對(duì)于FP系的語言來說沒有GC是無法正確工作的，所以我還是得接受GC這個(gè)東西。當(dāng)然我更喜歡的是將兩者互相結(jié)合的方式。
>> C/C++語言本身確實(shí)沒有太多MultiThead的支持，這種情況在C++0x出來后可望改變。但是，請(qǐng)記住C/C++永遠(yuǎn)傾向于你使用成熟的庫來解決問題。
C/C++不能適應(yīng)未來多核時(shí)代的發(fā)展，這個(gè)會(huì)是它沒落的原因。庫不能真正的解決問題，我們需要的是在語言層面的進(jìn)一步發(fā)展。
>> 指針是C/C++過于靈活的體現(xiàn)。使用指針的代碼可以寫得很丑陋，但一樣可以很優(yōu)雅。——這一點(diǎn)上用何種語言不會(huì)有區(qū)別。我相信，可以寫出優(yōu)雅的Java代碼，那么也一定可以寫出同樣優(yōu)雅的C/C++代碼。而反之則未必(因?yàn)橛行〤++某些范式是Java所不能支持的)。C/C++語言中的選擇太多，這的確是令人困惑的，但不見得是劣勢。我對(duì)C/C++程序員的建議是，多了解和使用C++標(biāo)準(zhǔn)庫，而不是過于糾纏指針相關(guān)的細(xì)節(jié)。
>> 算法優(yōu)化是程序設(shè)計(jì)的關(guān)鍵。但是通常情況下，所有語言(包括C/C++)的程序員研究的是關(guān)鍵路徑的優(yōu)化。研究*p++是不是比p[i]快?我相信這是標(biāo)準(zhǔn)庫的實(shí)現(xiàn)者要考慮的事情。所不同的是，C/C++程序員也可以和標(biāo)準(zhǔn)庫的作者一樣去考慮這些細(xì)節(jié)，而其他語言的程序員被剝奪了這個(gè)權(quán)利。
說到優(yōu)化，話題就多了。我曾經(jīng)向C#的Dictionary中插入了1億條整數(shù)(從1萬多個(gè)文本文件中讀入)，結(jié)果發(fā)現(xiàn)程序運(yùn)行了整整一個(gè)下午仍然沒有完成。而我改用C++的std::map，20分鐘就搞定了。再試試對(duì)50萬條自定義的結(jié)構(gòu)體數(shù)據(jù)進(jìn)行排序，我相信你和我一樣，會(huì)深深喜歡上C++的的高效而優(yōu)雅。
多年以前程序員們還在C程序里面內(nèi)聯(lián)匯編以實(shí)現(xiàn)代碼級(jí)的優(yōu)化，但是如今已經(jīng)沒有人這么做了，因?yàn)镃PU越來越復(fù)雜了，大多數(shù)情況編譯器做的比手工的要好?，F(xiàn)如今的Java/.NET的JIT引擎也已經(jīng)能夠達(dá)到非常高的優(yōu)化水平，在性能上C代碼的優(yōu)勢已經(jīng)越來越不明顯了。對(duì)于未來而言代碼級(jí)的優(yōu)化也已經(jīng)不再是重點(diǎn)，哪個(gè)語言可以適應(yīng)多核的發(fā)展，誰就將成為性能的王者。
>> 新生的語言，必然會(huì)在吸收舊的語言上基礎(chǔ)上進(jìn)行改進(jìn)?？匆粋€(gè)語言的生命力，并不在于看它某些地方存在的不足。事物會(huì)發(fā)展，并趨于完善。相信C++0x出來后，C/C++語言又將獲得新的生命力。單看Java、C#等幾個(gè)新一代的語言，其中有如此多的C++烙印，就證明了C/C++的影響是巨大的。動(dòng)不動(dòng)說一門語言死了，是一種淺薄。
說一門語言死了，不是說完全消失，而是退出主流開發(fā)語言行列，逐漸的被邊緣化，這些年鼓吹C/C++的人已經(jīng)越來越少了，在很多開發(fā)領(lǐng)域C/C++的地位已經(jīng)被Java、.net、腳本語言等所取代。C++0x出不出來已經(jīng)不重要了，倒是C++/CLI的出現(xiàn)帶給C++一些新意，不過雖然我很欣賞C++/CLI，但是它不會(huì)成為主流。在多核到來的時(shí)候目前編程語言還沒做好準(zhǔn)備，未來我們要面臨的不是2核4核而是百核千核這樣的規(guī)模，這不光要在算法領(lǐng)域繼續(xù)發(fā)展，編程語言也要來一次重大的變革才能適應(yīng)這種發(fā)展，至于方向在哪里，F(xiàn)P系的語言或許會(huì)給你帶來一些啟示。
>> 內(nèi)存管理是程序設(shè)計(jì)中最經(jīng)典的話題。GC無疑是內(nèi)存管理一個(gè)偉大的變革，但是我只是把它看作內(nèi)存管理的一個(gè)解決方案，而認(rèn)為不是的解決方案。比GC更加優(yōu)雅的方案不見得沒有。我比較傾向于在特定的情況下選擇合適的內(nèi)存管理方案，而不是沒有任何選擇的余地，而這正是C/C++的偉大之處。 所有那些GC語言(如Java、C#等)均把這個(gè)解決方案強(qiáng)加給程序員，這一定程度上來說減輕了程序員的負(fù)擔(dān)，但是也同時(shí)約束了程序員的主觀能動(dòng)性。"分配內(nèi)存和釋放內(nèi)存在C語言中都是很慢的"?不知道作者從哪里獲得的結(jié)論。
實(shí)話說我也不喜歡GC，沒有GC的C也可以工作的很好，但是對(duì)于FP系的語言來說沒有GC是無法正確工作的，所以我還是得接受GC這個(gè)東西。當(dāng)然我更喜歡的是將兩者互相結(jié)合的方式。
>> C/C++語言本身確實(shí)沒有太多MultiThead的支持，這種情況在C++0x出來后可望改變。但是，請(qǐng)記住C/C++永遠(yuǎn)傾向于你使用成熟的庫來解決問題。
C/C++不能適應(yīng)未來多核時(shí)代的發(fā)展，這個(gè)會(huì)是它沒落的原因。庫不能真正的解決問題，我們需要的是在語言層面的進(jìn)一步發(fā)展。
>> 指針是C/C++過于靈活的體現(xiàn)。使用指針的代碼可以寫得很丑陋，但一樣可以很優(yōu)雅。——這一點(diǎn)上用何種語言不會(huì)有區(qū)別。我相信，可以寫出優(yōu)雅的Java代碼，那么也一定可以寫出同樣優(yōu)雅的C/C++代碼。而反之則未必(因?yàn)橛行〤++某些范式是Java所不能支持的)。C/C++語言中的選擇太多，這的確是令人困惑的，但不見得是劣勢。我對(duì)C/C++程序員的建議是，多了解和使用C++標(biāo)準(zhǔn)庫，而不是過于糾纏指針相關(guān)的細(xì)節(jié)。
>> 算法優(yōu)化是程序設(shè)計(jì)的關(guān)鍵。但是通常情況下，所有語言(包括C/C++)的程序員研究的是關(guān)鍵路徑的優(yōu)化。研究*p++是不是比p[i]快?我相信這是標(biāo)準(zhǔn)庫的實(shí)現(xiàn)者要考慮的事情。所不同的是，C/C++程序員也可以和標(biāo)準(zhǔn)庫的作者一樣去考慮這些細(xì)節(jié)，而其他語言的程序員被剝奪了這個(gè)權(quán)利。
說到優(yōu)化，話題就多了。我曾經(jīng)向C#的Dictionary中插入了1億條整數(shù)(從1萬多個(gè)文本文件中讀入)，結(jié)果發(fā)現(xiàn)程序運(yùn)行了整整一個(gè)下午仍然沒有完成。而我改用C++的std::map，20分鐘就搞定了。再試試對(duì)50萬條自定義的結(jié)構(gòu)體數(shù)據(jù)進(jìn)行排序，我相信你和我一樣，會(huì)深深喜歡上C++的的高效而優(yōu)雅。
多年以前程序員們還在C程序里面內(nèi)聯(lián)匯編以實(shí)現(xiàn)代碼級(jí)的優(yōu)化，但是如今已經(jīng)沒有人這么做了，因?yàn)镃PU越來越復(fù)雜了，大多數(shù)情況編譯器做的比手工的要好?，F(xiàn)如今的Java/.NET的JIT引擎也已經(jīng)能夠達(dá)到非常高的優(yōu)化水平，在性能上C代碼的優(yōu)勢已經(jīng)越來越不明顯了。對(duì)于未來而言代碼級(jí)的優(yōu)化也已經(jīng)不再是重點(diǎn)，哪個(gè)語言可以適應(yīng)多核的發(fā)展，誰就將成為性能的王者。
>> 新生的語言，必然會(huì)在吸收舊的語言上基礎(chǔ)上進(jìn)行改進(jìn)?？匆粋€(gè)語言的生命力，并不在于看它某些地方存在的不足。事物會(huì)發(fā)展，并趨于完善。相信C++0x出來后，C/C++語言又將獲得新的生命力。單看Java、C#等幾個(gè)新一代的語言，其中有如此多的C++烙印，就證明了C/C++的影響是巨大的。動(dòng)不動(dòng)說一門語言死了，是一種淺薄。
說一門語言死了，不是說完全消失，而是退出主流開發(fā)語言行列，逐漸的被邊緣化，這些年鼓吹C/C++的人已經(jīng)越來越少了，在很多開發(fā)領(lǐng)域C/C++的地位已經(jīng)被Java、.net、腳本語言等所取代。C++0x出不出來已經(jīng)不重要了，倒是C++/CLI的出現(xiàn)帶給C++一些新意，不過雖然我很欣賞C++/CLI，但是它不會(huì)成為主流。在多核到來的時(shí)候目前編程語言還沒做好準(zhǔn)備，未來我們要面臨的不是2核4核而是百核千核這樣的規(guī)模，這不光要在算法領(lǐng)域繼續(xù)發(fā)展，編程語言也要來一次重大的變革才能適應(yīng)這種發(fā)展，至于方向在哪里，F(xiàn)P系的語言或許會(huì)給你帶來一些啟示。