從CSDN上讀到一篇文章，深有同感，原文如下：
傳統上認為，C++相對于目前一些新潮的語言，如Java、C#，優勢在于程序的運行性能。這種觀念并不完全。如果一個人深信這一點，那么說明他并沒有充分了解和理解C++和那個某某語言。同時，持有這種觀念的人，通常也是受到了某種誤導（罪魁禍首當然就是那些財大氣粗的公司）。對于這些公司而言，他們隱藏了C++同某某語言間的核心差別，而把現在多數程序員不太關心的差別，也就是性能，加以強化。因為隨著cpu性能的快速提升，性能問題已不為人們所關心。這叫“李代桃僵”。很多涉世不深的程序員，也就相信了他們。于是，大公司們的陰謀也就得逞了。
這個文章系列里，我將竭盡所能，利用一些現實的案例，來戳破這種謊言，還世道一個清白。但愿我的努力不會白費。
軟件工程
一般認為，使用Java或C#的開發成本比C++低。但是，如果你能夠充分分析C++和這些語言的差別，會發現這句話的成立是有條件的。這個條件就是：軟件規模和復雜度都比較小。如果不超過3萬行有效代碼（不包括生成器產生的代碼），這句話基本上還能成立。否則，隨著代碼量和復雜度的增加，C++的優勢將會越來越明顯。
造成這種差別的就是C++的軟件工程性。在Java和C#大談軟件工程的時候，C++實際上已經悄悄地將軟件工程性提升到一個前所未有的高度。這一點被多數人忽視，并且被大公司竭力掩蓋。
語言在軟件工程上的好壞，依賴于語言的抽象能力。從面向過程到面向對象，語言的抽象能力有了一個質的飛躍。但在實踐中，人們發現面向對象無法解決所有軟件工程中的問題。于是，精英們逐步引入、并拓展泛型編程，解決更高層次的軟件工程問題。（實際上，面向對象和泛型編程的起源都可以追溯到1967年，但由于泛型編程更抽象，所以應用遠遠落后于面向對象）。
一個偶然的機會，我突發奇想，試圖將貨幣強類型化，使得貨幣類型可以采用普通的算術表達式計算，而無需關心匯率換算的問題。具體的內容我已經寫成文章，放在blog里：http://blog.csdn.net/longshanks/archive/2007/05/30/1631391.aspx。（CSDN的論壇似乎對大文章有些消化不良）。下面我只是簡單地描述一下問題，重點還在探討語言能力間的差異。
當時我面臨的問題是：假設有四種貨幣：RMB、USD、UKP、JPD。我希望能夠這樣計算他們：
RMB rmb_(1000);
USD usd_;
UKP ukp_;
JPD jpd_(2000);
usd_=rmb_;//賦值操作，隱含了匯率轉換。usd_實際值應該是1000/7.68=130.21
rmb_=rmb_*2.5;//單價乘上數量。
ukp_=usd_*3.7;//單價乘上數量，賦值給英鎊。隱含匯率轉換。
double n=jpd_/(usd_-ukp_);//利用差價計算數量。三種貨幣參與，隱含匯率轉換。
而傳統上，我們通常用一個double或者currency類型表示所有貨幣。于是，當不同幣種參與運算時，必須進行顯式的匯率轉換：
double rmb_(100), usd_(0), ukp_(0), jpn_(2000);
usd_=rmb_*usd_rmb_rate;
ukp_=(usd_*usd_ukp_rate)*3.7;
double n=jpd_/((usd_*usd_jpd_rate)-(ukp_*ukp_jpd_rate))
很顯然，強類型化后，代碼簡潔的多。并且可以利用重載或特化，直接給出與貨幣相關的輔助信息，如貨幣符號等（這點我沒有做，但加上也不復雜）。
在C++中，我利用模板、操作符重載，以及操作符函數模板等技術，很快開發出這個貨幣體系：
template<int CurrType>
class Currency
{
public:
Currency<CurrType>& operator=(count Currency<ct2>& v) {
…
}
public:
double _val;
…
};
template<int ty, int tp>
inline bool operator==(currency<ty>& c1, const currency<tp>& c2) {
…
}
template<int ty, int tp>
inline currency<ty>& operator+=(currency<ty>& c1, const currency<tp>& c2) {
…
}
template<int ty, int tp>
inline currency<ty> operator+(currency<ty>& c1, const currency<tp>& c2) {
…
}
…
總共不超過200行代碼。（當然，一個工業強度的貨幣體系，需要更多的輔助類、函數等等。但基本上不會超過500行代碼）。如果我需要一種貨幣，就先為其指定一個int類型的常量值，然后typedef一下即可：
const int CT_RMB=0;//也可以用enum
typedef Currency<CT_RMB>RMB;
const int CT_USD=1;
typedef Currency<CT_USD>USD;
const int CT_UKP=2;
typedef Currency<CT_USD>USD;
const int CT_JPD=3;
typedef Currency<CT_USD>USD;
…
每新增一種貨幣，只需定義一個值，然后typedef即可。而對于核心的Currency<>和操作符重載，無需做丁點改動。
之后，我試圖將這個貨幣體系的代碼移植到C#中去。根據試驗的結果，我也寫了一篇文章（也放在blog里：http://blog.csdn.net/longshanks/archive/2007/05/30/1631476.aspx）。我和一個同事（他是使用C#開發的，對其更熟悉），用了大半個上午，終于完成了這項工作。
令人喪氣的事，上來就碰了個釘子：C#不支持=的重載。于是只能用asign<>()泛型函數代替。之后，由于C#的泛型不支持非類型泛型參數，即上面C++代碼中的int CurrType模板參數的泛型對等物，以及C#不支持泛型操作符重載，整個貨幣系統從泛型編程模式退化成了面向對象模式。當然，在我們堅持不懈的努力下，最后終于實現了和C++中一樣的代碼效果（除了那個賦值操作）：
assign(rmb_, ukp_);
assign(usd_, rmb_*3.7);
…
我知道，有些人會說，既然OOP可以做到，何必用GP呢？GP太復雜了。這里，我已經為這些人準備了一組統計數據：在C#代碼中，我實現了3個貨幣，結果定義了4個類（一個基類，三個貨幣類）；重載30個算術操作符（和C++一樣，實現10個操作符，每個類都得把10個操作符重載一遍）；6個類型轉換操作符（從兩種貨幣類到第三貨幣類的轉換操作符）。
這還不是最糟的。當我增加一個貨幣，貨幣數變成4個后，數據變成了：5個類；40個算術操作符重載；12個類型轉換操作符重載。
當貨幣數增加到10個后：11個類；100個算術操作符重載；90個類型轉換操作符重載。
反觀C++的實現，3個貨幣時：1個類模板；1個賦值操作符重載模板；10個算術操作符重載模板；外加3個const int定義，3個typedef。
10個貨幣時：1個類模板；1個賦值操作符重載模板；10個算術操作符重載模板；const int定義和typedef分別增加到10個。
也就是說C++版本的代碼隨著貨幣的增加，僅線性增加。而且代碼行增加的系數僅是2。請注意，是代碼行！不是類、函數，也不是操作符的數量。而C#版本的代碼量則會以幾何級數增加。幾何級數！！！
這些數字的含義，我就不用多說了吧。無論是代碼的數量、可維護性、可擴展性C++都遠遠好于C#版本。更不用說可用性了（那個assign函數用起來有多難看）。
我知道，有些人還會說：貨幣太特殊了，在實踐中這種情況畢竟少見。沒錯，貨幣是比較特殊，但是并沒有特殊到獨此一家的程度。我曾經做了一個讀取腳本中的圖形信息，并繪圖輸出的簡單案例，以展示OOP的一些基本概念，用于培訓。但如果將其細化，可以開發出一個很不錯的腳本繪圖引擎。其中，我使用了組合遞歸、多態和動態鏈接，以及類工廠等技術。就是那個類工廠，由于我使用了模板，使得類工廠部分的代碼減少了2/3，而且沒有重復代碼，更易維護。關于抽象類工廠的GP優化，Alexandrescu在其《Modren C++ design》中，有更多的案例。同樣的技術，還可以推廣到業務模型的類系統中，優化類工廠的代碼。
如果還不滿意，那么就去看看boost。boost的很多庫實現了幾乎不可想象的功能，比如lambda表達式、BGL的命名參數等等。它為我們很多優化軟件代碼新思路，很多技術和方法可以促進我們大幅優化代碼，降低開發成本。
最后，如果你認為C#的最大的優勢在于.net平臺，那我可以告訴你，這個世界上還有一種東西叫C++/CLI，完全可以滿足.net的開發，而且更好，足以擦干凈.net那骯臟的屁股。不過，這將會是另外一個故事了…