我學習使用C++，已經有差不多7，8年了。從當年在學校寫小程序，到后來在公司寫程序做設計。從VC++(雖然它不是標準C++)，到后來嵌入式的C++，到現在在項目中，標準的C++。坦白說，C++確實很復雜，和Java, Objective-C，Python，Ruby這些語言比，它確實很復雜。這種復雜來自于幾個方面：

　　[1] 編程的模式太多。面向過程，基于對象，面向對象，泛型。而且在面向對象的時候，它可以多繼承(真正的多繼承，不是那種多個接口一個父類的)，虛繼承，私有繼承。

　　[2] 標準庫的想法很完美，可是坦白說，庫的級別太底層。舉個例子std::string，沒有提供一個函數可以將所有substr替換成另外一個，你需要自己用find和replace寫一個;沒有一些標準的庫，譬如單元測試，Logger庫。我知道有Boost，可是有的平臺boost不能編譯通過。

　　[3] 語言細節太詭秘，而且編譯器之間有差別(實現)

　　我覺得[1]不是什么本質的問題，而是我們對待C++的問題。本來支持的東西多是好事，而且C++承諾你不用到一個屬性的時候，這個屬性存在不會拖你效率的后腿。一開始，我們根本不需要掌握多繼承，虛擬繼承，私有繼承。因為這些在絕大多時候都用不上。只會共有繼承，繼承的時候用單個基類和多個接口(就是全部是純虛函數)的那種，然后結合設計模式。基本可以解決設計上90%的問題。然后，你要知道C++有其他繼承的這些功能，當你熟練了前面那些東西以后，并且發現在項目中確實上面的東西解決不了設計上的問題的時候，用上新的技術來解決問題。

　　[2] 這個東西就不好說了。雖然標準庫設計的不錯，但是對使用人員要求太高。現實中，合格的C++程序員真的不多，或者換個角度說，庫做的還不夠，有的時候它太靈活。我承認用C++的項目對性能都要求很高，但確實不需要那么高。所以，其實C++的標準庫可以提供另一個好用但性能稍微有些缺陷的庫，我們是可以接受的。就目前SL里面的string, io，這些庫，真的需要改進。還有增加hashtable，增加logger，和UnitTest庫。

　　[3] 這個問題和1一樣，用到的時候再去了解，不用了解的太仔細。想當年，我把重載規則爛熟于心，現在還是忘的一干二凈。因為太復雜太細節了。

　　現在我來看，雖然C++很復雜，但我至今認為它的功能是非常強大的。我是指在系統設計上，它支持的范式是如此之多。它的復雜性是因為我們太想掌握它的所有，其實，我們應該掌握那部分我們應該掌握的：

　　面向過程，設計對象，面向對象，標準庫。然后看看設計模式，多線程，操作系統的接口。然后就是多寫程序，多看好的代碼(我強烈建議不要看爛代碼)。然后，就是開始用C++的思路去設計系統。在設計中去找到C++這些特性的應用場景，再去掌握它。那個時候，你就會自然而然的理解為什么有私有繼承，需要多繼承，需要虛繼承，需要模板。你很多時候就會恍然大悟，哦，原來

　　當然了，C++仍然缺乏一些其他語言的特性，我覺得：垃圾回收和反射。即使在電信金融這種項目中，垃圾回收都是有好處的。至少這個特性應該可選。反射，Java的反射可以為Java帶來很多有用的設計方法，C++沒有這個(0x也沒有)。另外，我覺得C++的頭文件機制也有必要修改(如果可以的話)。

　　當然，如果有個新項目來，我現在會首先考慮Java。因為C++對整個團隊要求太高。而且開發效率太低了。在對性能要求很高的地方我用C++，其他不關鍵的地方我用Java，再變動大的地方我會選擇用lua這種嵌入式語言。不使用模板，或者非常小范圍的使用。不為別的，就好比設計模式沒普及之前，面向對象經常被誤用;模板設計模式沒有普及或者總結之前，在大項目中少用模板，有益處。