并非偏見也駁“駁‘C語言已經(jīng)死了‘”

2019-11-17 05:49:09

字體：大中小

供稿：網(wǎng)友

　　>> 有偏見的永遠(yuǎn)只是個體，而不是群體。作者加了后面那句，無疑證實(shí)有偏見的不是C/C++程序員，而正是他自己。　　錯了，真理是站在少數(shù)人這邊的，當(dāng)一種變革將發(fā)生的時候，帶有偏見往往是大眾是傳統(tǒng)力量。

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

上一篇：淺薄與偏見駁“C語言已經(jīng)死了”

下一篇：C++/CLI中有效使用非托管并列緩存