本來只想對C++贊嘆復(fù)贊嘆，后來就失控了，接著情緒化了，最后終于開始爆走，語無倫次。
平心而論，C的而且確小巧精致，一切通通透透。老夫真心喜歡用它來編碼，但一旦動(dòng)用真格了，就立馬葉公好龍，就會(huì)懷念C++的種種好處，class、 template、 virtual、 析構(gòu)函數(shù)、甚至異常、const、引用等等，原來，離開了之后，才明白你的種種美妙動(dòng)人之處，因此，朕已決定，有生之年，假如還在編碼，那么C++，在心目中的，將是無可替代，它的一切，即便缺點(diǎn)，也是那么地令人回味無窮。因?yàn)樗囊磺校瑢⒆杂韶瀼氐降祝浞肿鹬赜脩舻倪x擇，不輕易剝奪用戶的權(quán)利，更不強(qiáng)求用戶用什么樣的方式做設(shè)計(jì)。所謂自由的世界，獨(dú)立的人格，手持C++利器，雖不敢說橫行天下，但起碼能愉快地編碼。只有C++，當(dāng)一個(gè)人獨(dú)立使用，如此的耐人尋味，歷久常新。多人一塊開發(fā)，簡直是大災(zāi)難，沒必要的封裝，種種自制的破爛輪子（前幾年，出自本座手中的輪子不計(jì)其數(shù)，基本上慘不忍睹），錯(cuò)綜復(fù)雜，交叉引用的類關(guān)系。這在其他語言中難以出現(xiàn)的怪現(xiàn)象，在C++中，平常得很，再一次證明了C++的博大精深，包羅萬象。不說別的，就說C++中的最負(fù)盛名GUI框架MFC，其類層次的設(shè)計(jì)，糟糕透頂，而BCG的代碼注入，毫無創(chuàng)意，笨拙無比的命名，垃圾般狗屎般的代碼堆積，可怕的內(nèi)存消耗，令人眼界大開，MFC的資源消耗已經(jīng)夠厲害，相比之下，居然顯得那么節(jié)儉，而用BCG開發(fā)界面，居然比C#又或者JAVA做出來的軟件，還不卡，這一切，都證明了C++過人之處。愛死你了，C++。
近幾年來看到某些人不知出于何因，對C++橫加指責(zé)，說什么論效率不如C，論高級特性又不如其他的動(dòng)態(tài)語言，實(shí)在莫明奇妙。說什么C++中的inline、繼承、template破壞了模塊的分離，“用C語言1000行源碼能完成的工作千萬不要用C++重寫！”，實(shí)則用C++來寫根本就無須1000行，并且可以精簡那些字?jǐn)?shù)多的代碼行，并且還更加易讀易懂，更加容易維護(hù)，效率或許還能更快一點(diǎn)點(diǎn)，得益于內(nèi)聯(lián)。如果還覺得用C++寫1000行代碼沒有C那么漂亮，那只證明閣下沒能力駕馭C++，請不要對C++亂加指責(zé)。他們那些所謂的C高手的代碼，到處指針飛舞，又長又臭一再重復(fù)的表達(dá)式（本該內(nèi)聯(lián)大顯身手），著實(shí)讓人難受，當(dāng)然，不否認(rèn)他們的精妙設(shè)計(jì)。
縱觀他們對C++非議之例子，無一不暴露出其設(shè)計(jì)上的缺陷，本該成員函數(shù)指針大顯伸手，他們卻用上了虛函數(shù)；Template模式的函數(shù)（順序依次，調(diào)用幾本虛函數(shù)），本該做成全局函數(shù)，硬是整成員函數(shù)；多繼承中的鉆石抽象基類不該有任何東西，他們卻偏要放某些東西，最后沒辦法，在虛繼承中糾結(jié)。……所有這一切根本無損于C++，卻只顯現(xiàn)出他們的愚蠢與無知。想展現(xiàn)自己也言行獨(dú)立，到頭來卻做出拾人牙蠢之事。其實(shí)，他們更應(yīng)該感謝C++，是C++的包容，才容許了如此丑陋的設(shè)計(jì)。本座平生最不齒這群宵小，自己毫無主見，風(fēng)聞名人幾句驚世駭俗之話語，就跟著瞎起哄，國人的毫無道理的盲目跟風(fēng)，由來已久，也不必細(xì)表了。那些所謂的C高手，覺得用C能做出精妙的設(shè)計(jì)，為何用起C++就不行了，其實(shí)他們大可“用C做設(shè)計(jì)，用C++編碼”，這樣，根本就不會(huì)影響他們的偉大杰作構(gòu)思。
并且要做到如同C那樣的高效，C++中完全沒有問題，完全可以放下身段，將C++的抽象降低到C那樣的級別，在沒有獨(dú)立完整的概念之前，或者是沒有很好的理由，絕不用類來封裝代碼，禁用慎用C++的一切高級特性，好比虛函數(shù)、繼承、異常等。任何語言特性都可以寫出垃圾代碼，也容易用得不好，但不可因?yàn)檫@樣，就否定此種特性的價(jià)值。特性作用越大，就越微妙，就越容易濫用誤用。即此而觀，C++中，應(yīng)該以class最為難用，此關(guān)一過，必定神清氣爽。
的確，C中，你可以也必須面對一切細(xì)節(jié)，在這種惡劣的環(huán)境下，手上能用的武器，也只有函數(shù)、結(jié)構(gòu)體、數(shù)組和宏，程序員的潛能就這樣被迫出來，爆發(fā)出來了，做出最合乎本質(zhì)的設(shè)計(jì)，而這幾樣簡單武器，互相組合，居然可以用得如此出神入化，其效果鬼斧神工，巧奪天工，直可驚天地，泣鬼神，手法更是精彩繽紛，巧妙絕倫，令人目不接暇，但是，不管如何，始終缺乏管理細(xì)節(jié)的有效武器。
鄙人最驚嘆C++的一強(qiáng)悍之處，對于各種匪夷所思的變態(tài)問題，會(huì)有更加變態(tài)的解決方式，而且還不止一兩種，更可見其靈活多變自由豐富的個(gè)性，但眾多迥異特性又能如此和諧的共存，為什么？竊以為C++是強(qiáng)類型的靜態(tài)語言，雖然提供多種語言工具以讓碼農(nóng)愉快輕松地編碼，盡可能地在編譯時(shí)期發(fā)現(xiàn)更多錯(cuò)誤，各種微妙的語言特性不過是為了幫助碼農(nóng)愉快高效地編碼，少出錯(cuò)，他們可以用這些語言工具整理組織C的各種凌散的表達(dá)式。
因?yàn)镃中雖然能直面一切細(xì)節(jié)，卻缺乏管理細(xì)節(jié)的語言工具。所有C中的細(xì)節(jié)，幾乎可通過C++的各種豐富特性妥善整理，而效率的損失又甚少，并且，在其強(qiáng)大的靜態(tài)系統(tǒng)的分析，能多發(fā)現(xiàn)點(diǎn)問題。但是強(qiáng)類型只是工具而已，必須善加利用，但C++的碼農(nóng)不會(huì)受束縛，必要的時(shí)候，大可突破。鄙人就曾經(jīng)實(shí)現(xiàn)了一個(gè)微型的動(dòng)態(tài)系統(tǒng)，對象之間沒有用層次關(guān)系，都是平等的，但之間又能互相組合裝配拆除，達(dá)到多繼承的效果，又沒有多繼承的各種問題。雖然語法上別扭點(diǎn)，但習(xí)慣了就感覺挺不錯(cuò)。
要看到C++的對C代碼的變態(tài)重組，為此，隨便舉例，qsort是代碼上的典范境界，能排序所有的數(shù)組，只要提供了元素之間的比較函數(shù)，就能快速地排序，實(shí)至名歸。但它是弱類型，其正確性全靠程序猿手工輸入，參數(shù)出錯(cuò)了，編譯器也檢查不出來，當(dāng)然C高猿不大容易出錯(cuò)。只是，依賴于C++強(qiáng)大類型推導(dǎo)威力，通過template整成以下樣子，既不限制qsort的包容性，又不損失任何一點(diǎn)點(diǎn)效率
template<typename _Ty>
inline void Sort(_Ty* pItems, size_t nItemCount, int (__cdecl* funcCompare)(const _Ty&, const _Ty&))
{
int (__cdecl * _PtFuncCompare)(const void *, const void *);
union_cast(_PtFuncCompare, funcCompare); // 為忽弄編譯器的強(qiáng)類型檢查
qsort(pItems, nItemCount, sizeof(_Ty), _PtFuncCompare);
}
但已經(jīng)是強(qiáng)類型的了，C++猿用起來就不大容易出錯(cuò)了，并且元素的比較函數(shù)也更加容易編寫，沒必要再用指針了，個(gè)人而言，引用比指針好，最起碼少敲一下鍵盤，那行代碼的長度可減少了一個(gè)字符。這樣，用起來不是更爽嗎？
又好比消息循環(huán)，判斷消息類型，一遍又一遍地寫著重復(fù)的表達(dá)式，好比，msg.message==WM_LBUTTONDOWN，不好玩，干脆class一CMsg，繼承自MSG。好比這樣：
class CMsg : public MSG
{
public:
bool Is(DWORD nMsg) const{ return message==nMsg; }
};
于是以上的那行判斷語句，就精簡成msg.Is(WM_LBUTTONDOWN)，感覺應(yīng)該好點(diǎn)吧。這兩例的代碼整理手段，對C++來說稀松平常，但C中就做不出來了，大概也只能用宏了，但宏的問題，大家也知道。
又有人說，C++高手的修成要經(jīng)過兩次轉(zhuǎn)換，從C到C++，然后從C++回復(fù)C，實(shí)在異想天開，不值一曬，舍棄C++的強(qiáng)大類型檢查，欲與一切細(xì)節(jié)肉博，吾不見其高明。這不是什么C++高手，充其量也只是C高手，其苦心孤詣在C中模仿C++的面向?qū)ο蟮募總z，用C++來表達(dá)，不過小菜一碟，并且還不失強(qiáng)類型檢查，必要時(shí)，只須用聯(lián)合體或類型轉(zhuǎn)換忽悠編譯器。那些回歸C的高猿的C++代碼，其實(shí)，不甚精致。所以，大家也不必理會(huì)。只須老老實(shí)實(shí)地做出簡簡單單的設(shè)計(jì)，然后再用C++組織管理各種細(xì)節(jié)，大可將代碼寫得漂漂亮亮干干凈凈。
要謹(jǐn)記的是，只用那些熟悉有把握的語言特性，對于每一個(gè)用到的C++關(guān)鍵字，一定要清楚其背后的機(jī)制并且由此所帶來的各種副作用。最難用的就是class了，毫無必要的封裝， 比赤裸裸的代碼更加丑陋，請優(yōu)先選擇非成員函數(shù)。封裝的出現(xiàn)，是因?yàn)榇a的一再重復(fù)出現(xiàn)的需要，而并非想當(dāng)然地推理演繹。只要是重復(fù)代碼，不管是一行表達(dá)，連續(xù)多行，分散跨行，都可以給予包裝在一起，只需一個(gè)函數(shù)調(diào)用。
再次重溫C++的核心設(shè)計(jì)，盡可能利用靜態(tài)強(qiáng)類型，盡可能地在編譯期中找出程序的錯(cuò)誤，提供多種豐富特性，協(xié)助碼農(nóng)充分地發(fā)揮強(qiáng)類型的一切優(yōu)點(diǎn)，對抗一切細(xì)節(jié)，對抗一切重復(fù)代碼，并且不必付出任何不必要的代價(jià)。當(dāng)然，強(qiáng)類型只是忠實(shí)的奴仆，完全不必因?yàn)樗w就你的設(shè)計(jì)，想要忽悠它，方法多種多樣。 有人說，C++的語言特性太凌散，不系統(tǒng)，好像打補(bǔ)丁似的。但鄙人覺得挺好的，特性分散，各自為政，可隨意自由組合，你討厭某個(gè)特性，大可不必理睬，它就靜靜地站在一旁，絲毫不影響你的代碼，這不就是設(shè)計(jì)的最高境界嗎。
好了，終于狠狠地出了口惡氣。在下承認(rèn)很情緒化，有失高手風(fēng)范。