強大不表明完美——C++幾個不方便的地方。

引言：

本文自工做以來使用過C++、Java、Python、Groovy、Objective C、Lisp，我最初學的就C++的，當時對她情有獨鍾，靈活和強大充分體現了她的智慧，隨着你對她理解的深刻，你會發現隨便一段代碼會有很大的優化餘地，以至於大牛和小菜寫的代碼有很大的區別，舉個十常簡單的例子，串拷貝你們都熟悉吧（至少是一道常考的面試題，我也常常拿此考考應屆生 ）：

數據結構書上的最終版是這樣的（注意：本文全部代碼都不是商用版本，爲了簡潔，沒注意風格的良好性）：

void strcpy(char* des, const *char src) {
    while(*des++ = *src++);
}

最原始版本是這樣寫的：

void strcpy(char* des, const char* src) {
    while(*src != '\0')
    {
        *des = *src
        des++
        src++;
    }
}

固然，中間仍是許多進化版本，不是一步跳過來的，具體請參考譚浩強的《數據結構》，這裏只是說明一樣的功能，能夠充分利用C++語言靈活語法寫出很是精煉的代碼，這裏利用到的語言特性有：操做符優先級、結束符'\0'等價於0或NULL、非0即爲真。這只是個簡單的例子，若是應用類指針、泛型、虛繼承等特性，就能夠在大項目中作出不少優化，使得代碼精煉且高效。

（題外話：有不少書和文章出於易讀性原則，不鼓勵第一種風格，我以爲沒那麼糟糕，若是是經常使用的，人人都熟練某一段，這樣寫就至關於單詞縮寫，就比如設計模式同樣是一種共同語言，你一說關鍵字，人家馬上就明白這一整塊代碼）

總之，C++給個人感受就是：只有想不到，沒有作不到。

可是當我學過其它語言以後，發現C++並非我想像中的完美，每種語言都有本身獨到的智慧，雖然並非每一種我都熟悉，但她們的設計思想讓我受益不淺。若是說C++靈活，那世上還有另外一種靈活，通過幾年工做的提煉，我發現C++有這些不方便之處。

如下是我當前想到的：

.頭文件：

這是我發現的每個不方便的地方，這件事由來還挺曲折離奇的，我學的第二種語言是Java，當時是爲了開發ZTE第一個Android的機頂盒，當時那裏只有一兩我的懂Android，並且立刻就要離職了，因此就只有趕鴨子上架了，叫我去學Java，開發Android應用，我當時仍是惟C++獨尊，帶着鄙視Java的情緒去學習Java，第一天，寫了個HelloWorld，發現Java居然沒有頭文件，當時內心就想這是什麼扯淡語言，頭文件都沒有，那我怎麼提供接口給別人還不用暴露個人實現。但後來，隨着學習的深刻，發現Java根本就不須要頭文件，它的接口信息都包含在.class裏了，甚至還會包含接口的註釋。

不用頭文件，編程時顯示要方便一點，改函數名的的時候不用改兩個文件了，由於那顯然有冗餘的工做量，即然是冗餘就應該讓機器去作，不要耽誤人的時間。因此我以爲能夠在C編譯成的*.o文件前面部分放入接口信息，這樣別人引用能夠像Java或Objective C或Python這樣import了。

.函數必須先申明再調用：

【注意這裏說的不是變量的先申明再使用】這個規矩至關難受，其實只要編譯器搜索一遍本文件，就能夠找出寫在後面的函數了，這樣只是耽誤一點編譯時間，即不會影響運行效率，還可使人少寫些代碼並減小人放錯的機率，何樂而不爲呢？

.成員變量申明時不能初始化：

我想多數人學C++時，都會天然而然的認爲成員變量申明的時候就能夠給他賦個初始值，像這樣：

// file1.cpp
class Foo
{
    int bar = 0; //wrong in C++, but legal in Java
}

在C++是容許這樣的，按照官方的說法，申明文件是屬於類的而不是屬於對象的，無論他怎麼說，Java也能夠申明時定義，我以爲這樣很方便，也符合人的思考習慣，其實你能夠當成初始化值來理解，不管如何，這條規定來了不便。

.標準庫不強大：

相比Java的標準庫，C++的STL實在是太薄弱了，就幾個容器類，什麼網絡編程，加密算法都沒有，所有都獲得網上找開源的庫，同時使得人人都要造車輪，大大的加長了開發週期，更延緩了C++自身的發展。

.API註釋：
Java的.class文件裏已包含了註釋，使得在集成開發環境裏，能夠邊編程邊查看API說明，以下圖：

我以爲C++也能夠把註釋打包到.o和.so文件裏，這樣別人用你的庫的時候就不會找你要文檔（你還頗有可能沒寫）或問題你怎麼用了，固然這個功能應該可配置，以知足一些擔憂庫被泄漏的用戶。

.作Linux開發沒有一個好用的集成開發環境：

這個雖然跟C++語言自己沒有多大聯繫，但這多是作C++的工程師的一塊痛處，這條可能會有不少人反對，有人會以爲能夠經過配置vim或emacs（這個東西不必定好使，倒是一個很好的「裝逼」利器，我也研究過，的確頗有面子，特別是在新手MM面前）來使用強大的功能，配置複雜不說（有一個哥們用的emacs有3000行的配置文件，不過那人是興趣緣由），也不是很好用，顯然沒有window上的VS和Eclipse開發Java那麼智能，用Eclipse開發Java歷來都沒用擔憂編譯問題，在C++上可能只經過邊寫邊手動頻繁的辦法來減小編譯問題帶來的痛苦。還有人會以爲集成開發環境很差，會使得程序員對編譯細節和程序的生成過程全然不知，這個我之前也這麼認爲，還專門學習研究編譯和可執行文件，還絞盡腦汁看過龍書（Alfred V. Aho寫的編譯原理），但後來發現沒什麼用處，如何不是寫編譯器，那些知識很難派上用場，長此以往，我都忘了。因此我認爲，程序員應該有更多的時間去思考軟件的設計和架構，而不是那些簡單又繁瑣的編譯工做，更不該該天天去重複作這些事情，應儘量讓機器去作。好比說自動完成功能能夠大大提升輸入效率；自動顯示API註釋功能使得不須要先查文檔才知道使用；寫註釋也很方便，只需在方法前輸入「/**」再輸入回車，就會自動完成API註釋結構，包括參數名，以下圖：

邊寫邊後臺編譯的使得再不用擔憂編譯錯誤，還有錯誤提示並給出建議方案，以下圖：

函數未返回值給出的建議，若是你點擊第一個選項，就會自動幫你加上一行"return 0;"，下圖到達不了的代碼兩個示例，有提示

   

還有重構功能，在Eclipse中重構很簡單，好比你改一個函數名，他會自動幫你更改全部調用處，包括其它的工程，這個功能蘋果家的XCode也有，你用C++估計得使用一番Ctrl+F、Ctrl+C、Ctrl+V了，若是次日又想改回來，你又得痛苦了。除此以後還有其它不少強大的功能，在此就不一一列舉了。

.匈牙利命名法：

這個好像也跟C++關係不大，不過實際上也是因爲IDE不強大形成的，我想有人但願看到這種命名法寫的代碼，沒人喜歡寫這種命名法的代碼，特別是有時想改某個變量的類型時，如int型改char型，這個時候你就得一個個改了，其實本質是要看到類型信息，看看強大的IDE是怎麼作的：

在鼠標懸停的時候自動顯示了，類型信息根本就不要在變量名上體現，我還據說這種命名法是微軟發明，我在想他微軟爲什麼不直接改一下VS的代碼增長這個功能而去增長他千千萬萬的員工的工做量呢，更想不通的是爲什麼還流行了這麼多年，難道沒人發現這個問題嗎，仍是我想錯啦。

說明：本文章純屬我的觀點，不保證絕對正確，歡迎你們批評和指正，同時我本身也會對本文不斷的更新和完善。