開發者是否該學習C++語言

　　隨著C++ 11和C++ CX的引入，很多人重新燃起了對這門語言的興趣。不少開發者，尤其是Windows開發者，都想知道是否應該放棄C#和Java，轉而支持C++。John Sonmez認為這並不需要。

　　在“為什麼C++並沒有‘王者歸來’(Why C++ Is Not ‘Back’)”一文中，John Sonmez認為只有如下三個原因才會使用C++：

　　● 需要搾干軟件每一寸可能的性能，並且想用支持面向對象抽象的語言來實現。

　　● 編寫直接面對硬件的代碼。(例如，編寫底層驅動。)

　　● 內存控制與定時極為重要，因而系統的行為必須是完全確定的，還必須能夠手動管理內存。(想一下控制機器移動部件的嵌入式實時操作系統。)

　　Herb Sutter高度稱贊了這篇文章，認為文中的“觀點有些深度，沒有誇張”。關於C++的應用場景，他又做了一些補充：

　　● 服務，依賴於運行時會更為困難。

　　● 測試，對比一下全部或者大部分采用靜態鏈接的應用程序與在最終用戶機器上往往是首次執行時才編譯或即時編譯(JIT)的應用程序，後者無法完整地測試。

　　John Sonmez反對學習C++，過於復雜是原因之一。即使C++ 11讓開發容易了一些，但是程序員仍然不得不學習各種老式的C++編碼方法。“你會碰到20年前的C++代碼，看起來就像是完全不同的語言。”為了加強其觀點，他向准備應聘C++職位的開發者提出了36個問題。下面列出幾條：

　　1.在C++中，基本數據類型有多少種初始化方式?你能都說出來嗎?

　　12.什麼是復制構造函數，何時會用到?尤其是與賦值操作符相比，你能區分嗎?

　　16.在C++中，何時適合通過引用來返回值，何時不適合?

　　33.為什麼絕對不應該在析構函數中拋出異常?

　　反對C++的另一個理由是“編程語言真正需要的是簡化並提高抽象層次，而不是反其道而行之”。他繼續道，

　　編寫底層代碼的需求總是存在的，但我們今天編寫的大部分都是較高層次的代碼。

　　很多年前，當我終於無法再堅持認為我用C++開發應用的速度比C#快時，我跳下了C++這條船。

　　我堅持良久，試圖讓自己相信我在C++上的所有投入並沒有白費，但是事實證明， C#帶來的簡化是如此之大，以至於與此相比，C++所提供的額外的力量並不值得這些額外的付出。

　　在文章結尾，John Sonmez說到，學習C++對於理解計算機的一般工作原理仍然是有用的，“但是我認為C++不會東山再起，這是好事”。

　　關於這一點，Alo補充到：

　　我是從C++開始的，而且我職業生涯的前四年都花在了C++上。這種經驗對我非常有價值，正如您的文章中所指出的那樣，因為一旦把C++學到了足夠的水平，就可以很快地撿起其他任何語言;此外，還能從一個更低的層次上更深刻地理解軟件工作原理——如果從其他層次更高的語言開始學習編程，獲得這種知識的難度就大多了。正因如此，我一直不贊成讓程序員從Java開始學起。

　　Richard Dunks反駁到：

　　我認為，在第一學期的程序設計導論課程和數據結構的教學中，C++是沒什麼幫助的，因為光實現就要耗費很多時間，反而讓同學們忽略了他們要復現的結構。我很高興自己能夠精通C++，但我認為這並不值得，而且C++絕對不是一門萬能的教學語言。

　　Stephen Cleary有一條評論談到了可重用性：

　　我原來是C++開發者，幾年之前，市場的壓力讓我成了一名C#開發者。C#的確更有生產率，但是完全不可能實現C++模板那種級別的代碼復用。

　　經典的例子就是容器、迭代器和算法這三駕馬車。在C++中，能夠創建一個用於任何容器的算法，而且可以在編譯時對算法加以調整以便必要的情況下利用隨機訪問能力。你可以用C#試試。這還是尚未談到“新C++”的情況;1998年的C++對代碼復用的支持就比現在的C#好了。

　　關於性能，Herb Sutter給出了如下建議：

　　在任何語言中，如果非常關注性能，都會大量使用數組(未必“總是”使用，只是“大量”用到)。不過這在有些語言中很容易，可以很好地控制一般內存布局，特別是控制數組;而在其他語言或環境中就困難一些(有可能讓你使用，但更為困難)，如果這些語言或運行時特別偏愛通過指針構造的數據結構，你就不得不 “放棄”或者“盡量避開”。

　　除了在Herb Sutter和John Sonmez的相關博客上的大量高質量評論，Reddit的Programming和Coding子群組也有很多可以學習的東西。

　　參考英文原文：Should Developers Start Learning C++?

　　文章來源：伯樂在線