|
【CSDN 報(bào)道】昨天由CSDN發(fā)布的Linux之父發(fā)表了對(duì)C++的不滿之后，很多的軟技術(shù)專家們就這一問題提出了自己的觀點(diǎn)，隨后諸多位網(wǎng)友也積極參與了討論，現(xiàn)在展示給大家的就是他們的精彩語錄。 支持觀點(diǎn)： 1，網(wǎng)友roy_hu C++野心太大，希望包羅萬有，以致語義實(shí)在是太復(fù)雜了。而這個(gè)復(fù)雜性在我看來是不必要的，因?yàn)樗?/font> 增加了 一的抽象方式，functional programming就很不錯(cuò)。 2，網(wǎng)友Atry 基本來說C++太復(fù)雜了，很多特性用不到，可能是我比較初級(jí)吧，不過感覺C++的抽象能力要想用同樣的C 實(shí)現(xiàn)出來，并不是短時(shí)間就能達(dá)到并超越的。 因?yàn)樾率挚梢杂妹嫦驅(qū)ο笳Z言寫出過程化程序，而老手可以用過程化語言寫出面向?qū)ο蟮某绦颉?/font> 我被當(dāng)頭一棒之后最大的感悟就是，應(yīng)該把 C++ 看成是比 C 更低級(jí)的語言。這樣，使用 boost 和模板 的時(shí)候就不會(huì)因?yàn)樗鼈儙淼膲奈兜蓝胸?fù)罪感了。 把 C++ 看成是比 C 更低級(jí)的語言，還有一個(gè)暗示，就是在接口上，用 C 函數(shù)加結(jié)構(gòu)，而不用帶復(fù)雜繼 承結(jié)構(gòu)的類。因?yàn)?，繼承也被我看成是一種在模塊內(nèi)部實(shí)現(xiàn)中便于 設(shè)計(jì)層面的東西。 “...唯一真正重要的部分是設(shè)計(jì)...”Linus大師一語道破天機(jī)！ 3，網(wǎng)友wangor 1.我很牛 2.我寫C++很牛 3.可是我寫C比寫C++更牛 4.我和linus一樣牛 4，網(wǎng)友 missdeer 其實(shí)用C實(shí)現(xiàn)一個(gè)程序，也是有一些模式的，這些模式?jīng)Q定了如何使用C的某些突出的特性。寫C程序如果 能用好宏與函數(shù)回調(diào)，就足以滿足很多程序了。用C的好處就是，我能掌握每一塊內(nèi)存在哪里。 5，網(wǎng)友 cnm 用C++的人大部分都有一個(gè)心智上的問題，以至?xí)钟|，鄙視一些自己不喜歡的東西。兒子太頑皮，東搞 搞西搞搞，爸爸教訓(xùn)一下不務(wù)正業(yè)的兒子，兒子就不認(rèn)爸爸了，甚至要把爸爸消滅，爸爸也很生氣，發(fā) 誓要給兒子更嚴(yán)厲的教訓(xùn).... 中立觀點(diǎn)： 1，網(wǎng)友Linker M Lin 同樣的設(shè)計(jì)思路來做一件工作, C/C++ 在模塊api 級(jí)別的區(qū)別: C 的話, 模塊之間用 free function, function point, handle, struct 來定義接口 C++ 用 interface (abstract class), class 來定義接口 C++ 的方式是耦合度更高的方式, 哪些function 屬于哪個(gè) class, class 之間的關(guān)系, 出現(xiàn)在了 API 這層, 導(dǎo)致了云風(fēng)說的修改框架帶來的麻煩問題. C 的 API 方式耦合度更低些. 從另外一個(gè)角度講, C++ 的方式更白盒, 會(huì)讓 API 的使用者更能夠理解模塊內(nèi)部的一些邏輯關(guān)系, 從而 更有可能使用正確 --- 代價(jià)就是, 邏輯關(guān)系一旦變化, 就比較麻煩. 2，網(wǎng)友zcpro 博主說的沒錯(cuò)，關(guān)鍵是設(shè)計(jì)。我也是個(gè)喜歡簡(jiǎn)潔的人，但我還是在用c++，因?yàn)閏++的資源太多了。我現(xiàn) 在傾向于這樣使用c++，使用c++的抽象能力做設(shè)計(jì)，定義模塊接口，這里只用虛函數(shù)，不用其它復(fù)雜的 高級(jí)特性，類似com的做法；然后在實(shí)現(xiàn)模塊時(shí)程序員愛怎么寫就怎么寫，只用c也可以，呵呵。 3，網(wǎng)友Cofyc 語言的進(jìn)化一定是為了能寫出邏輯復(fù)雜度更高，用現(xiàn)在的眼光來看更為龐大的應(yīng)用。為了達(dá)到這個(gè)目標(biāo) ，抽象能力是最關(guān)鍵的一點(diǎn)，因?yàn)檫@能幫助程序員理解復(fù)雜的系統(tǒng)。所以，如果是做較為大型的應(yīng)用的 話，不管用什么語言，抽象能力都是很關(guān)鍵的。不要看windows的api都是c接口，那是為了兼容（其實(shí)也 并非都是c接口，很多高級(jí)應(yīng)用早就使用com了，現(xiàn)在又有了.net）。不用害怕重寫或者重新設(shè)計(jì)接口， 重構(gòu)是不可避免的，只要每次重構(gòu)能離目標(biāo)更近。如果兼容是很重要的，那么就保留舊模塊，然后設(shè)計(jì) 新接口新模塊，象directx做的那樣，不是挺好的。
反對(duì)觀點(diǎn)： 1，網(wǎng)友 Atry 樓主的帖子可以總結(jié)為一句話“使用C++設(shè)計(jì)代碼不如C” 進(jìn)而顛覆了C++的設(shè)計(jì)目標(biāo)“抽象、封裝和代碼重用” 那么這些目標(biāo)不正確么？回答當(dāng)然是否定的，否則就不會(huì)有java和C#大行其道。 那么有10軟件開發(fā)經(jīng)驗(yàn)，使用C++編寫了數(shù)以10W計(jì)的代碼的樓主，為什么會(huì)轉(zhuǎn)而選擇C而棄用C++呢?對(duì)于linus教主的言語會(huì)產(chǎn)生如此強(qiáng)烈的共鳴？ 回答這個(gè)問題，可以從二人從事的工作上得到答案。樓主是國內(nèi)著名游戲引擎的開發(fā)者，而linus則是專 注于os內(nèi)核的開發(fā)者和維護(hù)者。他們進(jìn)行軟件開發(fā)的設(shè)計(jì)決策都是以“性能”優(yōu)先的。 孟老大說，linus曾經(jīng)試圖使用C++寫內(nèi)核，后來失敗了；而樓主也把使用C++完成的游戲引擎重新用C來 寫。我想可能是面對(duì)同樣問題的時(shí)候，設(shè)計(jì)決策影響了他們對(duì)語言的選擇，畢竟C所擅長(zhǎng)的，C++不如。 但是世界上有如此之多的成功的C++軟件項(xiàng)目，是否使用C重寫能夠帶來更好的效果呢？ C++仍然是C的進(jìn)化，雖然它包含了太多的東西使它難以掌握，但是它仍然變得越來越好。特別是C++0x中 可能做出對(duì)于線程模型和GC的修訂，有助于使用者更好的完成設(shè)計(jì)。 2，網(wǎng)友david 論了那么多還是請(qǐng)大家不要忘記C不過是C++的一個(gè)子集.用不用C++的那些特性是使用者自己在經(jīng)過考慮 過后得出的.自己選擇的東西最后反過來批判只能說明當(dāng)初悟道不深亦或者現(xiàn)在還未悟道.語言所做的只 是提供一些認(rèn)為可以在某些情況某些環(huán)境下能夠幫助使用者更好編碼的特性.記住,用不用在于你自己,誰 也沒有強(qiáng)迫你非要那樣或這樣.不過是提供多一種選擇罷了.所以所有討論的焦點(diǎn)不是語言的好壞而是你 為什么做出這樣的選擇. 3，網(wǎng)友lxlxdw 好吧，我來唱唱反調(diào)。 學(xué)習(xí)期。 c，簡(jiǎn)單，干練。簡(jiǎn)單到?jīng)]什么好學(xué)的。有用的技能都是在實(shí)際運(yùn)用中獲得exp然后lvup的?？?/font> 以這么說，初學(xué)者可以很快得掌握c，但是基本上卻什么都不能做。立竿不能見影。這是c的簡(jiǎn)單干練所 決定的，是必然的。 c++，復(fù)雜，強(qiáng)大。c++的這些特點(diǎn)已經(jīng)無須論證。遍地開花的垃圾c++程序員用鐵 一般的事實(shí)說明了一切。針對(duì)于與c的比較，仍然來說說立竿見影的問題。我的觀點(diǎn)是，雖然這一點(diǎn)c++ 做得比c好一些，但是仍然不能達(dá)到立竿見影的程度。結(jié)論，就這個(gè)階段來說，不分勝負(fù)。 開發(fā)期。在任何軟工項(xiàng)目都處于“硬件受限”的時(shí)代和環(huán)境下，c是毫無疑問的王者。（當(dāng)然，如果你腦 容量可堪負(fù)荷，請(qǐng)使用asm）但是在現(xiàn)在，情況分2種。第1種，我是一個(gè)獨(dú)裁者。當(dāng)我需要清楚地知道我 的代碼做了什么的時(shí)候，c->asm仍然是最適合的合作者。這種人多半是戰(zhàn)斗在“硬件受限”的原始時(shí)代 。Linus就處于這樣一種時(shí)代，所以他不得不用c。不要告訴我linux可以跑在多么牛B的機(jī)器上，內(nèi)存可 以多么的大，這是p話，linux的kernel必須不能用盡一切可以觸及的資源，因?yàn)樗皇且粋€(gè)承載其他東 西的方舟，他必須委屈自己假裝是在一個(gè)超級(jí)受限的環(huán)境下工作，把美味的梨子讓出來給依賴著它的兄 弟姐妹們。所以，kernel類的開發(fā)者毫無疑問是戰(zhàn)斗在一個(gè)“硬件受限”的原始時(shí)代，c->asm是他們最 好的合作者。 ps.游戲引擎也算半個(gè)“硬件受限”環(huán)境。雖然不需要承載如kernel般繁多的東西，但是 引擎最終將被用來產(chǎn)生實(shí)作品，從設(shè)計(jì)者的角度出發(fā)，也必須在一定規(guī)?！獩]錯(cuò)，就是規(guī)?！峡?/font> 慮到由這個(gè)引擎所生產(chǎn)出來的東西將要產(chǎn)生的負(fù)荷——這毫無疑問地成為了一個(gè)“受限”的環(huán)境。—— 但是盡管如此，c->asm也不一定就是最優(yōu)解，在我的觀點(diǎn)來看，這是語言無關(guān)的——當(dāng)然，目前可以做 出的選擇不多，就個(gè)人而言，我仍然選擇了c++。第2種，我是一個(gè)追求高產(chǎn)的商人。在性能要求不太嚴(yán) 苛的情況下，c就是一個(gè)渣。太多的東西需要自己去做，這意味著將會(huì)帶來冗長(zhǎng)的開發(fā)周期，這會(huì)導(dǎo)致成 本的急劇增長(zhǎng)，包括各種可量化的（人力物力財(cái)力）和不可量化的（團(tuán)隊(duì)穩(wěn)固性團(tuán)隊(duì)士氣）成本。因此 ，在這種環(huán)境下，c就是一個(gè)渣。c++毫無疑問比c做得好。但是，在這個(gè)領(lǐng)域里，c和目前的c++都已經(jīng)失 去了輝煌的寶座，新生代的 負(fù)。但是c在這一階段具有穩(wěn)定、明確的應(yīng)用領(lǐng)域，算是小勝吧。 運(yùn)行期。仍然是分成2種情況，效率關(guān)鍵和效率不關(guān)鍵的。在避開其他環(huán)節(jié)的情況下，前者當(dāng)然比后者更 受歡迎。但是，運(yùn)行期的效率直接與開發(fā)期的質(zhì)量相關(guān)，因此運(yùn)行期的事又是不可能和開發(fā)期完全隔開 的。 “不管用什么樣的語言，都可以寫出糟糕的程序。”——這話也可以反過來說，“用任何一種語言 ，都可以寫出優(yōu)秀的程序。” 因此，在我眼中，這仍然是一個(gè)語言無關(guān)的問題。不要把失敗的理由放在 你無法控制的地方，優(yōu)秀的進(jìn)化者會(huì)改變自己適應(yīng)環(huán)境?！@是我的觀點(diǎn)，因此，我更希望自己能成 為“用任何一種語言，都可以寫出優(yōu)秀的程序”這樣一個(gè)開發(fā)者。我認(rèn)為，每一個(gè)以成為優(yōu)秀開發(fā)者為 目標(biāo)的程序員，都應(yīng)該以這樣一種精神為指導(dǎo)，雖然不一定要確實(shí)地做到，但是應(yīng)該具備這樣一種精神 。用更容易理解的話來說，就是要做到手中有劍心中無劍（請(qǐng)注意這跟武俠小說上的說法是反的-_-!） 結(jié)論，既然都語言無關(guān)了，當(dāng)然沒有勝負(fù)之說。 維護(hù)期。 OK，這實(shí)際上是一個(gè)軟工項(xiàng)目中生命周期最長(zhǎng)的階段。這里涉及了很多東西，最主要的就是3 個(gè)方面：調(diào)試、維護(hù)、復(fù)用。這三個(gè)議題每一項(xiàng)都可以大書特書再書還要書。既然是生命期中最長(zhǎng)的一 個(gè)階段，因此c對(duì)c++的重量級(jí)攻擊放在這里當(dāng)然就會(huì)很有效果。在維護(hù)上的代價(jià)而言，結(jié)構(gòu)過程化的c比 抽象對(duì)象化的c++便宜太多了。這是“結(jié)構(gòu)過程化”與“抽象對(duì)象化”的根本不同所造成的差別。用程序 員們更能夠理解的方式來說，c就像一個(gè)鏈表，要增減head很方便；而c++就像一個(gè)動(dòng)態(tài)數(shù)組，要insert [0]或者remove[0]就要牽一發(fā)而動(dòng)全身！但是，c真的就很好維護(hù)么？非也！一個(gè)瘋狂使用#define的c程 序，不會(huì)比一個(gè)濫用oo特性的c++程序更好調(diào)試和維護(hù)。因此，這仍然是與開發(fā)期工作的質(zhì)量息息相關(guān)的 。結(jié)論，好吧，我不得不說，在我眼中c和c++仍然不分勝負(fù)。 綜上所述，c和c++在我眼中不分好壞，具有同等的地位。他們分別代表了兩種不同的編程思想。 “結(jié)構(gòu) 過程化”的c帶來的好處是賦予程序員更為強(qiáng)大的控制力，和維護(hù)期可以“斷章取義”的靈活性——但是 代價(jià)是更多你不得不親歷親為的工作。 “抽象對(duì)象化”的c++帶來的好處是更為貼近現(xiàn)實(shí)的思維要求， 以及更具親和力的“人機(jī)交互接口”——當(dāng)然，代價(jià)是需要你練好足夠的基本功來了解c++在背后到底做 了些什么，以及在維護(hù)期和復(fù)用階段你可能要面臨的“抽筋”式的痛苦。 作為一個(gè)擁有美好愿望的程序員，我希望有一種語言，既能給我c的強(qiáng)大控制力和維護(hù)期的靈活性，又能 給我c++的親和力和強(qiáng)大的——好吧，我承認(rèn)我比較喜歡template那種拐彎抹角的東西——腦力訓(xùn)練（— _,—），然后，又能輕易地滿足KISS的原則——這將可以讓我非常簡(jiǎn)單地找到高質(zhì)量的合作者——畢竟 怪物級(jí)的c/c++程序員不是像現(xiàn)在的本科生一樣遍地都是。而且基于c/c++的靈活性——這里叫做不確定 性更好——這一特征，每個(gè)怪物級(jí)的c/c++程序員都有很大可能不能跟另一個(gè)怪物互相咬合他們腦袋里高 速轉(zhuǎn)動(dòng)的齒輪——如果你非要那么做，這很可能會(huì)帶給你更多的機(jī)會(huì)讓你的項(xiàng)目走火入魔，甚至停擺， 最后以自爆收?qǐng)觥?/font> 但是遺憾的是，目前這只能是一個(gè)美好的愿望而已，我不得不采取折中的辦法來找一些代替品。因此， 目前我的做法是，用c的規(guī)則來寫c++的程序，略微地用一些可以被我完全控制的c++的特性（模板的編譯 期編程技術(shù)很贊，可以為運(yùn)行期的效率和正確性帶來很大的好處），最根本的出發(fā)點(diǎn)是建立在獲得強(qiáng)大 控制力和可預(yù)期的維護(hù)期工作量的目的之上的，當(dāng)然，還有不能忽視的效率問題——我的目標(biāo)是一個(gè)可 擴(kuò)展的游戲引擎。 胡言亂語了一堆也不知道說了些啥……最后做個(gè)總結(jié)性發(fā)言吧：c和c++都不是什么好東西，但是正如 windows也不是什么好東西一樣，我們卻非得要用它們——至少在可以預(yù)見的一段不會(huì)算短的時(shí)期內(nèi)。 另外，撇開c/c++的比較說點(diǎn)跑題的話。 c++目前確實(shí)處于一個(gè)相當(dāng)尷尬的境地，高不成低不就，過于復(fù)雜龐大的身軀又成為了他能夠被更熟練掌 握的門檻。c++目前有兩條路可走，一是朝c退過去，二是朝更高之處攀登。但是無論走哪一邊，都是“ 強(qiáng)敵環(huán)視”，要想闖出一片新的天空，恐怕需要?jiǎng)ψ咂h了。至于是不是一定要偏著走，偏又要怎么個(gè) 偏法，我也說不出個(gè)所以然來，且讓我們拭目以待吧。而c，很可能將會(huì)止步于“硬件受限”的時(shí)代吧， 然后在這個(gè)時(shí)代和環(huán)境下再一點(diǎn)一點(diǎn)地進(jìn)化，最終與c++將來的終點(diǎn)完全分道揚(yáng)鑣。 個(gè)人以為，程序語言的發(fā)展以后將會(huì)明確地分出兩個(gè)方向，一個(gè)是以c為代表的“底層親和”的語言，它 們的特點(diǎn)是將給于程序員最大的控制能力，讓一切盡在程序員的掌握之中。另一個(gè)將是以不斷發(fā)展的新 興高級(jí)語言為代表的方向，也可能是c++以后的方向，它們的特點(diǎn)是不斷地將底層的東西從程序員的眼前 隱藏起來，讓程序員的門檻降得更低，充分地體現(xiàn)出KISS原則，并從而提高生產(chǎn)力和生產(chǎn)效率。 |
|
|
