網路上似乎一直有種說法：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 型別在有的機器上是有符號的，而在其他機器上可能是無符號的。
C語言的缺點
正如前文討論的，C語言的“天平”更加偏向機器，這使得C語言程式設計師的工作量增加不少。有一些 Java 程式設計師甚至說：“C語言程式設計師花費一個月開發的程式執行需要 0。05 秒，而我只需要一天就能開發出這樣的程式，它執行只需要 0。1 秒，所以，C語言快嗎？”
C語言的缺點
雖然略微誇張了一些，但是的確應該考慮這樣的問題。一般來說，C語言程式本身的確會比其他程式語言程式快一些，但是有些專案的確不需要那麼快，它們對 deadline 的要求更加苛刻，這時可能C語言就不再那麼合適了。
因此，C語言程式的效率的確高，但它是以犧牲程式設計師開發效率換來的。這其實決定了它與其他程式語言的應用領域，如果追求資源消耗以及效率的極致，那麼C語言無疑是最佳的選擇。這個領域以嵌入式領域為代表。如果專案更多追求的是開發效率，那麼C語言顯然就不是合適的人選了。
點個贊再走吧
歡迎在評論區一起討論，質疑。文章都是手打原創，每天最淺顯的介紹C語言、linux等嵌入式開發，喜歡我的文章就關注一波吧，可以看到最新更新和之前的文章哦。
未經許可，禁止轉載。