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