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

對于編寫的函數，除了明確的指定契約外，在函數開始處應該對傳入的參數進行檢查，確保非法參數傳入時立即報告錯誤信息。例如：

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 ) ) ;  
}  
對指針的檢查尤其要注意，通常程序員會這樣進行檢查：  
// 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兩種情況，應該是系統中當時只需要處理這兩種情況，但是如果后期系統需要處理更多的情況，而此時上面這部分代碼又沒有及時更新，或者是因為開發人員一時疏忽遺漏了。一個可能導致系統錯誤或者崩潰的bug就出現了，而使用ASSERT可以及時地提醒開發人員他的疏忽，盡可能快的消滅這個bug。

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

一些好的代碼風格也能夠幫助你避免一些幼稚的、低級的錯誤，而這種錯誤又是很難檢測到的。由于C++語言簡潔靈活的特性，有時候敲錯一個字符。或者漏敲一個字符，都有可能造成極大的災難，而這種錯誤并不是隨著你的編程水平和經驗的提高就能逐步避免的，誰都會敲錯字符，對吧。

比如程序員經常將等于邏輯判斷符==誤敲成賦值運算符=，對于我來說就不太可能程序運行出錯后才發現，因為我的習慣是，對于邏輯判斷，將常量置于==的左邊，如果我誤輸入了=，那么編譯的時候編譯器就會報錯。

法），無異于因噎廢食。”在所有可用C和C++的領域，C++都是比C更好的語言。當我說“更好的”時候，我說的是C++擁有比C更安全的類型檢查、更好的抽象機制、更優秀的庫。當然，凡事都有例外，如果你做的項目1）不大。

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

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

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

不過，也許最可能的是他會說：“問題是我們今天用的C++并非如此（簡潔），你的假設不成立。”是的，我的假設不成立。但雖然我們無法消除復雜性，我們實際上是可以容易地避開復雜性，避短揚長的。這也是本文的要點，容我后面再詳述。

當然，到現在你可能還是會說。我還是不用C++語言，因為我可以用D；或者如果你本來做的項目就不需要C++，你則可能會說，我用Python。首先，如果你的項目能用Java/Python乃至Ruby做，那么用C++是自討苦吃。

因為能用那些語言代表你的項目在效率上本身要求就不高，那么用一門效率上討不到太大好處，復雜性上卻綽綽有余的語言，有什么價值呢？其次，如果你的項目效率是很重要的，你可能會說可以用D。