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