C++是一門廣泛用于工業軟件研發的大型語言。它自身的復雜性和解決現實問題的能力，使其極具學術研究價值和工業價值。和C++語言一樣，C++已經在許多重要的領域大獲成功。 

C++吸引如此之多的智力投入，以至于這個領域的優秀作品，包括重量級的軟件產品、程序庫以及書籍等，數不勝數。文題“C++程序設計之四書五經”一個不太嚴格的含義是：C++程序設計之四書五經。是的，在本文（及其下篇）中，我將分門別類推薦20多本C++好書，你可以根據自己的需要選讀。

TCPL和D&E

TCPL和D&E分別是《The C++ Programming Language》和《TheDesign and Evolution of C++》的簡稱，均出自Bjarne Stroustrup之手。我將它們單列出來，首先是因為Bjarne是C++語言的創建者，然后是因為比“首先”那個原因更重要的原因：這兩本書是C++領域毋庸置疑的杰作。說它們是C++語言圣經，并不為過。

迄今為止，TCPL是除了C++標準文獻之外最權威的C++參考手冊。和大多數人的看法不大一樣，我認為Bjarne的文字語言并不遜色于他所創建的程序語言，至少我喜歡這種學院氣息濃厚的作品。#t#

本書對C++語言的描述輪廓鮮明、直截了當。它從C++語言創建者的角度來觀察C++，這是任何別的作者和書籍做不到的— 沒有任何人比Bjarne自己更清楚該怎么來使用C++。這是一本嚴肅的著作，以中、高級C++開發人員為目標讀者。如果你是一名有經驗的C++程序員，需要了解更加本質的C++知識，本書正是為你而寫。

它不是那種讓你看了會不斷竊喜的小書，需要用心體會，反復咀嚼。在閱讀過程中，請特別留心Bjarne先生強調了什么，又對什么一語帶過。我個人比較喜歡這本書的第四部分“使用C++做設計”，這樣的內容在類似的程序設計語言書籍中很難看到— 我甚至認為Bjarne應該將這部分獨立出來單獨寫一本書。

首先重復一句Bjarne的話：“我們的系統已經是極度復雜的了，為了避開C++的復雜性而干脆不用C++（Linus的做法），無異于因噎廢食。”在所有可用C和C++的領域，C++都是比C更好的語言。當我說“更好的”時候。#t#

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

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

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

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

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

那么用一門效率上討不到太大好處，復雜性上卻綽綽有余的語言，有什么價值呢？其次，如果你的項目效率是很重要的，你可能會說可以用D。然而現實是D在工業界尤其是國內被運用得非常少，幾乎沒有。

而C++語言卻有大量的既有代碼，已經使用C++去做他們的產品的公司，在很長一段時間之內幾乎是不可能用別的語言重寫代碼的，正如Joel所說，決定重寫一個非平凡的代碼基==自殺。所以，我們至少要注意以下兩個明顯的事實