為什麼還用C編程？

傳統的那些選擇C而不是C++的理由的說服力已經逐漸地被削弱。還有什麼繼續使用C的更好的理由嗎？

一個 Dr. Dobb's的老讀者最近問我：為何人們還在使用C編程。這個話題最近曾在我們網站的評論中出現過。早期也曾出現在與一些行業公司的對話過程中，尤其是微 軟。在C++早期，根據你的需要，你可以有許多使用C或C++的理由；但隨著C++的演化，C的大量傳統的傑出特性已經變得不那麼優越了。考慮到 這些點一般是在比較兩門程式設計語言時首先會被考慮到的，因此我們來一起看一下。

效能。通常我們都認為C++應用的效能要比C的慢。但在大多主流平台上，這個效能上的差距在今天已經變得非常小了。比 如，Alioth上的電腦基準測試報告顯示C++(運行在32位Linux上)在運行基準測試時的效能要比C慢27%。其他一些研究結果顯示這個差 距或略大或略小些。但在幾乎所有例子中，C++都是僅次於C的運行第二快的程式設計語言。它通常要比運行在JVM和.NET平台上的語言快出很多。因 此，儘管C在基準測試上依舊保持有優勢，但對於大多已經可以接受Java效能的應用(比如公司專屬應用程式或面向用戶端的應用)而言，這個差距顯得並不是那麼重要 了。

普遍性。在嵌入式編程領域，C仍然保持著慣用語言的舒適地位，這緣於這樣一個事實：每個硬體供貨商都會提供一個C編譯器。而大家普遍 也認為C++在嵌入式開發方面表現沒有那麼強勢。不過，當今大多提供編程工具的組件供貨商也提供了C++編譯器。(但PIC微控制器方面繼續保持 著例外)。這是一個正在逐漸縮水的好處。

可移植性。C++曾被認為是一個可移植的老大難（實際上在C89標準出台以前，C也是一個老大難）。然而，當今的編譯器對C++語 言的核心實現的十分充分，以至於大多軟體可以通過重新編譯進行移植，不需要什麼調整。如果真的需要進行調整的話，請提供像Brian Kernighan曾經說過的那樣的使用語言中段的代碼（譯註：所謂語言中段的代碼，即那些平台無關，不涉及可移植性的代碼文法和元素）。庫的可移植 性是一個更令人頭疼的因素，不過C庫也存在同樣的問題。在C和C++中，編譯器的標準遵守程度迥異，因此使用那些沒有獲得全面支援的新特性 (C99、C11以及C++11）將會是一個內在的風險。也就是說，C89可能是世界上最具可移植性的代碼了。(為此，當可移植性成為最關心的事 情的時候，我們將選擇它。例如，Lua團隊就因此選擇了C，當然也同樣考慮到了效能因素)

應該說從效能、普遍性以及可移植性方面來講，C仍然對C++保持著優勢，但這種優勢正在逐步縮小。在這點上，C++社區做得非常出色，他們讓使用者 去處理那些實質性問題並採納。問題是：這些縮水的優勢對C++的好處是種補償嗎？這些好處包括物件導向，異常處理，更好的類型管理，模板，更豐富 的標準庫等等。沒有了這些好處，每個用C實現的工程可能感覺起來就像嘗試用一柄剪刀去修剪草坪。

那些特性無疑有助於代碼編寫，但卻要因此付出代價 – 複雜性，這也是C有別於C++的重要之處。C是為數不多的幾種規模短小、足夠簡潔的通用程式設計語言，你可以輕鬆掌握其全部內容。事實上我們確實可能需要 完整地瞭解一門語言的全部細節，並且還要充分瞭解其標準庫，達到無需查看API手冊即可使用的程度。我不相信這在其他主流語言中是可行的，C++，當然不行。

短小是語言的吸引力之一。你可以快速學習它並快速成為有效率的開發人員。簡潔則因另一個較少被談及的特性而被提高：極致的語言可讀性。我這裡指的是 語義上而不是文法上的。在語義方面，C中做某件事情的方法是有限的。因此，當你閱讀代碼時，無論是誰編寫的代碼，你會確切地知道代碼的行為。相反，C++ 做同一件事情有很多種方法 – C++開發人員喜歡的一種靈活性。正是由於C在這方面的清晰，它才成為一門用於編寫複雜基礎設施的卓越程式設計語言。也正是這個原因，JRockit JVM（現在Oracle的主要JVM）的原始作者選擇了C。在幾年前的一段對話中，他們闡述了他們選擇C而不是C++的觀點：他們可以更快速獲得開發 者；當深入到代碼中時，他們可以比使用C++更容易地理解這些代碼。

僅憑這一點，C語言仍然是系統層代碼的一個極佳選擇：它快速，可移植，易於閱讀和理解。對於那些更加強調開發效率的應用，無疑C++將繼續在原生語言中佔據主導位置，並且很可能擴大其足跡。