為什麼仍還用C編碼?

作者Andrew Binstock

概述:作者論述了C語言仍然屹立不倒,長久不衰的原因:過去C語言在效能和可移植上面有巨大優勢,但隨著時間的流逝其他語言(C++等)在效能和可移植上與C的差距越來越小.但為什麼C還很火.作者認為是因為C語言的簡潔性,使它在系統層級上仍然無可替代.但是對於應用程式開發還是選擇其他語言較好,因為開發效率更重要.

本文:

偏好C而非C++的傳統的理由正在慢慢的消逝.還有什麼好的理由仍然使用C嗎?

一個Dr Dobb's的長期讀者最近問我一個問題:為什麼人們還要用C去編碼.這個主題最近出現在發布在我們網站上的一些評論中,更早些時候也出現在與一些特別是來自Microsoft的業界人物的對話中.在C++的早期時候,有很多理由根據需求來選擇C還是C++；但是因為C++已經進化了,許多傳統的有區別的C的特性已經變得不那麼有優勢了.因為這些優點當比較二種語言時總是首先出現,我們來審視一下:

1. 效能. C++過去總是比起C慢很多.但是在許多主流平台上,在今天這區別已經很小了.例如,Alioth上的電腦標準檢查程式顯示在32位Linux上C++運行一系列測試比C要慢27%.其他調查顯示這種區別略高或略低.但是在大多數情況下,C++是除以外最快的語言.它通常要比JVM和.NET上的語言快多了.所以儘管C在標準測試上仍然有優勢,在大多數應用都能接受Java的效能情況下(比如,任何企業級應用或者面向用戶端的軟體),
這種區別並不嚴重.

2.普遍性.在C仍然作為慣用語言的嵌入式世界裡,偏愛C是因為每一個硬體廠商都提供C語言編譯器.過去C++在嵌入式世界裡並不強勢.然後今天大多數提供編程工具的組件廠商都會提供一個C++編譯器.(PIC 微控制器總是一個例外).這是一個在退化的優勢.

3. 可移植性.C++曾經很難移植(C89標準出現以前的C也一樣難移植).然而今天的編譯器已經足夠地實現了C++語言核心保證軟體可以在需要的情況下做很小的調整就能重新編譯,前提是代碼能夠像Brian Kernighan曾經說的在語言的中間寫.庫的可移植性是一個更多麻煩的因素,但是C語言庫也存在同樣的問題.對C和C++二個語言,各種編譯器對標準的支援程度差距非常大,所以使用沒有完全支援的特性(C99,C11和C++11)風險是一樣的.那就是說,C89可能是世界上最具移槙性的代碼了.(也是基於這個原因,當移槙性是絕對顧慮時總是選擇C語言.例如,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++會繼續統治著本地語言並且很可能會擴張它的足跡.

原文: Why Code in C Anymore?

原文下的評論也很有意思比如第一條JSawyer說到:他理解不了為什麼TIOBE把C列為第二受歡迎的語言.是不是因為Google搜尋時把++和#字元去掉了所以統計顯示人們搜尋的是"C Programming"?