2019-09-08 15:06:07 IT劉小虎

網絡上似乎一直有種說法：C語言程序運行時要比其他語言編寫的程序快得多，因為它“離底層機器很近”，這個說法正確嗎？如果正確，那究竟是什麼阻止了其他語言編寫的程序和C語言程序一樣快呢？

什麼阻止了其他語言編寫的程序和C語言程序一樣快呢？

C語言程序快是因為它簡單

編程語言其實就是程序員與機器溝通的一門“外語”，可以認為編程語言是為程序員和機器服務的。事實上，在設計編程語言時，常常需要在一些問題上取捨以尋求平衡，天平的兩端則分別是程序員和機器。

人類和計算機的思考方式是有很大差異的，因此如果某種編程語言偏向程序員，那麼可能程序員寫程序會很方便，但是最終得到的程序對機器就不夠友好了，效率會有損失。例如 Python，JavaScript 等腳本語言。

相反，如果某種編程語言偏向機器，那麼最終得到的程序效率會得到最大程度的提升，但是這樣的編程語言可能對於程序員就會不太友好，開發效率會有所降低。這類編程語言以C語言，以及彙編語言為代表。

開發效率會有所降低

C語言誕生時，計算機技術還不是很發達，這可能是影響“天平”平衡的一個重要因素。如今，新出現的一些編程語言通常都會更加“照顧”程序員，“垃圾回收”以及“動態類型”等機制幾乎已經成為標配了。

原因也很簡單，因為在如今快節奏（快到“浮躁”）的社會，開發效率低下的編程語言是無法得到廣泛發展的。

正如前文所說，當編程語言的“天平”向程序員傾斜時，最終得到的程序效率自然會有所降低。因為編程語言要“照顧”程序員是要付出代價的——“垃圾回收”等機制本身也會消耗相當一部分的計算機性能。雖然今天的計算機技術已經大大發展，但是計算機的運算能力始終是有限的。

計算機的運算能力始終是有限的

而C語言也沒有這些額外的機制，自然最終C語言程序的運行速度也會比別的語言程序高。當然，這也意味著C語言程序員需要自己管理分配的內存，自己避免內存溢出、洩漏等問題，還要自己處理變量的類型。

再來談談C語言

設計人員在設計C語言時，更多考慮的是最終C程序的運行效率，因此像下面這樣的幾種安全檢查，都要依賴程序員自己，C語言本身是不會檢查的：

數組的索引邊界
未初始化的變量值
內存是否洩漏
空指針的引用

以數組的應用為例，Java程序設計語言會在虛擬機中進行一些方法調用、綁定檢查以及其他的一些安全檢查。這是語言本身提供的服務，這些檢查隱藏在底層，對開發應用的程序員是不可見的。但是這樣的安全檢查無疑對程序員是友好的，因為它增加了應用的安全性。

安全檢查無疑對程序員是友好的

而在C語言程序開發中，即使是一些非常瑣碎的事情也要程序員自己處理。例如在執行 memcpy() 等內存操作時，是不會檢查要複製的內存區域是否有重疊的。

C語言的這些特性在有些程序員看來是缺陷，但其他一些程序員卻認為這是一種靈活，能夠讓程序員具有更大的權限的管理機器，以及獲得計算機的每一點性能。

雖然C語言號稱是一種支持可移植程序開發的編程語言，它的一些語法也盡力實現這一目標，但是C語言並不想強迫程序員以可移植的方式編寫代碼，以防止C語言成為“高級彙編語言”，畢竟編寫特定於機器的代碼是C語言的優勢之一。

C語言作為一門古老的編程語言，其熱度卻始終沒有減少，自然的，C語言近些年也是得到很多發展和拓展的，從C89到C90，再到C99，C11標準。但是C語言始終沒有偏離它的基本精神：

相信程序員，儘量把控制權交給程序員。
不阻止程序員做他想做的事，例如有時數組下標為負也允許 arr[-1]。
保持語言簡潔。
只提供一種操作方法。
保持C語言程序的高效率，即使可能會與可移植性相悖。

最後一句需要稍加解釋：生成高效的程序是C語言的最重要的優點之一。為了確保看似非常簡單的操作不會導致崩潰，C語言有時寧願在通用抽象規則上做出讓步，這也是C語言標準中有許多“未定義”的規則。

C語言有時寧願在通用抽象規則上做出讓步

例如，short int，int， long int 整數類型究竟佔用多少內存空間，C語言標準並沒有給出確定的定義，這就意味著這幾種整數類型在不同的機器上佔用內存空間大小可能是不同的。再比如，雖然C語言標準規定了 char 類型佔用一字節內存空間，但是卻沒有定義其符號，也就是說 char 類型在有的機器上是有符號的，而在其他機器上可能是無符號的。