C++語言積累了龐大的代碼基，這個(gè)代碼基不是一朝一夕能夠推翻的。D從語言角度來說的確優(yōu)于C++語言，但最關(guān)鍵的就是還沒有深入工業(yè)界，希望本文能教會(huì)你更多東西。

對(duì)于編寫的函數(shù)，除了明確的指定契約外，在函數(shù)開始處應(yīng)該對(duì)傳入的參數(shù)進(jìn)行檢查，確保非法參數(shù)傳入時(shí)立即報(bào)告錯(cuò)誤信息。例如：

BOOL GetPathItem ( int i , LPTSTR szItem , int iLen )  
{  
ASSERT ( i > 0 ) ;  
ASSERT ( NULL != szItem ) ;  
ASSERT ( ( iLen > 0 ) && ( iLen < MAX_PATH ) ) ;  
ASSERT ( FALSE == IsBadWriteStringPtr ( szItem , iLen ) ) ;  
}  
對(duì)指針的檢查尤其要注意，通常程序員會(huì)這樣進(jìn)行檢查：  
// An example of checking only a part of the error condition  
BOOL EnumerateListItems ( PFNELCALLBACK pfnCallback )  
{  
ASSERT ( NULL != pfnCallback ) ;  
} 

在上面的例子中，switch語句僅僅處理了GK_ENTITY_POINT和GK_ENTITY_PLINE兩種情況，應(yīng)該是系統(tǒng)中當(dāng)時(shí)只需要處理這兩種情況，但是如果后期系統(tǒng)需要處理更多的情況，而此時(shí)上面這部分代碼又沒有及時(shí)更新，或者是因?yàn)殚_發(fā)人員一時(shí)疏忽遺漏了。一個(gè)可能導(dǎo)致系統(tǒng)錯(cuò)誤或者崩潰的bug就出現(xiàn)了，而使用ASSERT可以及時(shí)地提醒開發(fā)人員他的疏忽，盡可能快的消滅這個(gè)bug。

還有一些情況，在開發(fā)人員編寫代碼時(shí)，如果能夠確信在某一點(diǎn)出現(xiàn)情況A就是錯(cuò)誤的，那么就可以在該處加上ASSERT，排除情況A。綜上所述，恰當(dāng)、靈活的使用ASSERT進(jìn)行主動(dòng)調(diào)試，能夠極大提高程序的穩(wěn)定性和安全性，減少調(diào)試時(shí)間，提高工作效率。

一些好的代碼風(fēng)格也能夠幫助你避免一些幼稚的、低級(jí)的錯(cuò)誤，而這種錯(cuò)誤又是很難檢測(cè)到的。由于C++語言簡(jiǎn)潔靈活的特性，有時(shí)候敲錯(cuò)一個(gè)字符?；蛘呗┣靡粋€(gè)字符，都有可能造成極大的災(zāi)難，而這種錯(cuò)誤并不是隨著你的編程水平和經(jīng)驗(yàn)的提高就能逐步避免的，誰都會(huì)敲錯(cuò)字符，對(duì)吧。

比如程序員經(jīng)常將等于邏輯判斷符==誤敲成賦值運(yùn)算符=，對(duì)于我來說就不太可能程序運(yùn)行出錯(cuò)后才發(fā)現(xiàn)，因?yàn)槲业牧?xí)慣是，對(duì)于邏輯判斷，將常量置于==的左邊，如果我誤輸入了=，那么編譯的時(shí)候編譯器就會(huì)報(bào)錯(cuò)。

法），無異于因噎廢食?！痹谒锌捎肅和C++的領(lǐng)域，C++都是比C更好的語言。當(dāng)我說“更好的”時(shí)候，我說的是C++擁有比C更安全的類型檢查、更好的抽象機(jī)制、更優(yōu)秀的庫。當(dāng)然，凡事都有例外，如果你做的項(xiàng)目1）不大。

編碼中用不到什么抽象機(jī)制，甚至ADT（抽象數(shù)據(jù)類型，例如std::complex這種不含多態(tài)和繼承的）也用不到，RAII也用不到，異常也用不到。你連基礎(chǔ)庫（如，簡(jiǎn)化資源管理的智能指針、智能容器）都用不著。那么也許你用C的確沒問題；所以如果你的情況如此，不用和我爭(zhēng)論，因?yàn)槲覠o法反駁你。我們這里說的領(lǐng)域大致是Bjarne在“C++應(yīng)用列表”里面列出來的那些地方。 #t#

底線是：如果把C++中的諸多不必要的復(fù)雜性去掉，留下那些本質(zhì)的，重要的語言特性，簡(jiǎn)化語言模型，消除歷史包袱。即便是C++的反對(duì)者也許也很難找到理由說“我還是不用C++”。在我看來，一個(gè)真正從實(shí)踐意義上理性反對(duì)使用C++語言的人只有一個(gè)理由：C++的復(fù)雜性帶來的混亂抵消乃至超過了C++的抽象機(jī)制和庫（在他的特定項(xiàng)目中）帶來的好處。

值得注意的是，這里需要避免一個(gè)陷阱，就是一旦人們認(rèn)定了“C++語言不好”，那么這個(gè)理由就會(huì)“長(zhǎng)出自己的腳來”，即，就算我們拿掉C++的復(fù)雜性，他們可能也會(huì)堅(jiān)持還是不用C++，并為之找一堆理由。我假定你不是這樣的人。

不過，也許最可能的是他會(huì)說：“問題是我們今天用的C++并非如此（簡(jiǎn)潔），你的假設(shè)不成立?！笔堑?，我的假設(shè)不成立。但雖然我們無法消除復(fù)雜性，我們實(shí)際上是可以容易地避開復(fù)雜性，避短揚(yáng)長(zhǎng)的。這也是本文的要點(diǎn)，容我后面再詳述。

當(dāng)然，到現(xiàn)在你可能還是會(huì)說。我還是不用C++語言，因?yàn)槲铱梢杂肈；或者如果你本來做的項(xiàng)目就不需要C++，你則可能會(huì)說，我用Python。首先，如果你的項(xiàng)目能用Java/Python乃至Ruby做，那么用C++是自討苦吃。

因?yàn)槟苡媚切┱Z言代表你的項(xiàng)目在效率上本身要求就不高，那么用一門效率上討不到太大好處，復(fù)雜性上卻綽綽有余的語言，有什么價(jià)值呢？其次，如果你的項(xiàng)目效率是很重要的，你可能會(huì)說可以用D。