再駁Linus:思科工程師對C++不得不說的事
原創(chuàng)【51CTO 新鮮譯文】 薩丕爾—沃爾夫假說曾經(jīng)在語言學研究領域風靡一時。我粗略總結(jié)了一下，這個假說的核心思想是：你使用的語言影響和制約了你的想法。例如，如果你的語言只有一個單詞來描述雪，你將很難說出粉狀雪和易碎的冰雹之間的差別。
當我了解后，我徹底不相信薩丕爾—沃爾夫假說。雖然語言相對論帶著一套假說卷土重來，但幾乎可以肯定的是，人類思想絕不受制于詞匯和語法的牢籠。
E.W. Dijkstra是編程語言領域的薩丕爾，他曾說過：
“給以前接觸過BASIC學生教良好的編程幾乎是不可能的。作為潛在的程序員，他們精神上已經(jīng)殘廢，無再生的希望。使用COBOL更是摧殘了他們的心靈，因此，教他們應該被視為刑事犯罪”。
今天，我們有Linus Torvalds對C++的炮轟，他認為使用C++的程序員會破壞他或她接觸到任何項目。Linus是這樣說的：
“我得出的結(jié)論是，任何希望在項目中使用C++而不是C的程序員都是很可能讓我生氣的程序員，因此我不會給他們機會來搞砸我的項目。C++導致真正糟糕的設計選擇。”
Torvalds太過武斷
在我所在的大型企業(yè)中，我們的名片背面有一句口號：不迷信科技。做到這一點可能不容易，但是的，我們愿意嘗試。
對我來說，這個訓誡意味著兩件事：
1、嘗試客觀地為工作選擇最佳的工具
2、不要讓你對工具的偏好指揮完成工作的方法
Linus在他的炮轟中已經(jīng)說得很清楚，任何使用C++編程的人都很心虛，拿這些規(guī)則做借口。
但我有不同的想法，我認為C++顯然也有可能成為完成工作最合適的工具。得出這樣的結(jié)論是相當客觀的，我認為Linus顯然是被他特殊的技術流派迷惑了。
一個簡單的例子
作為我上學期C/C++編程班的期末作業(yè)，我要求學生用C實現(xiàn)一個簡單的令牌計數(shù)程序，目標是要重現(xiàn)下面這段C++代碼的行為：
map counts; string s; while ( cin >> s ) counts[s]++; for ( auto ii = counts.begin() ; ii != counts.end() ; ii++ ) cout << ii->second << " : " << ii->first << endl;
這個特殊的程序突出了一些C中沒有的C++功能，如：
●C數(shù)組，向量多功能替換
● 字符串類
● 使用iostreams安全輸入
●關聯(lián)數(shù)組作為標準庫的一部分
這個程序用C++來寫是相當容易的，只需要處理一下輸入流中的錯誤——有時候甚至這一步都沒有必要。
用C實現(xiàn)
用C重寫是一個稍微復雜點的任務，因為C的庫中沒有任何類型的關聯(lián)數(shù)組。解決這個問題的辦法很多，我選擇了下面的辦法：
● 將所有令牌讀入一個數(shù)組
● 完成后，對數(shù)組排序
●完成數(shù)組排序后，通過遍歷每個令牌獲得計數(shù)
雖然這個算法占用的空間比C++程序更多。假設你沒有碰到gsort()之類病態(tài)的問題，花的時間可能都差不多。
我堅信用C++比用C寫這個程序更容易，理由如下：
●C I/O缺陷。在C中讀字符串有相當多的困難，由于C I/O庫沒有標準的方法讀取長度無限制的字符串(可以使用編譯器特定的擴展，但那會引起其它問題)，你的輸入代碼必須檢查多種錯誤情況，或者構建你自己的字符串輸入函數(shù)。
● C數(shù)組的內(nèi)存管理基本上是一項手工任務，我必須為數(shù)組分配原始空間，如果超出了它的長度，我還得小心重新分配，做完后，我還得釋放空間。
● C字符串的內(nèi)存管理有同樣的問題。
● 字符串數(shù)組的排序使用gsort()只是有一點不方便，gsort()不能提供C++庫中sort()函數(shù)的性能保證。
這個函數(shù)的C版本代碼行數(shù)要多一些，需要手工完成的任務也要多一些，因此犯錯的幾率也要大一些。
我喜歡C++版本的最后一個原因是，它同樣適合其它類型，如插入和提取運算符類型、比較運算符，都可以使用同樣的代碼，只需要變一個聲明。將實現(xiàn)同樣的事情的代碼轉(zhuǎn)換成一個函數(shù)模板，這樣就可以在以后直接拿來使用了。
我一些最好的朋友是C程序員
那么我偏愛C++版本就能說明我是一個語言偏執(zhí)的人嗎?
我認為不能如此下結(jié)論，首先，我認為這個程序的C版本也有一些不錯的優(yōu)點：
● 你可以使用POSIX系統(tǒng)調(diào)用編寫這個程序，除了內(nèi)存分配和排序。
●這個程序的C版本因為使用了底層I/O，速度將會更快，C++ iostreams在任何時候都表現(xiàn)良好，但它們的分層方法在談到效率時總是處于不利地位。
因此，對于這樣一個程序，語言的選擇最終歸結(jié)為背景，如果你相信80/20規(guī)則，并且它不是程序的核心部分，你可能認為這個代碼應該用C++編寫。代碼行數(shù)越少，犯錯的幾率就越低，效率可能不是最大的問題。
如果這是一段很關鍵的經(jīng)常執(zhí)行的代碼，你可能會認為C是最佳選擇。如果選擇C，請一定要花點額外的時間進行代碼評審，確保沒有內(nèi)存泄露和指針錯誤，只有那樣，你才上路了。
撫平Linus的情緒
那么Linus看到上面的代碼是如何炮轟的呢?我斗膽猜一下，任何像樣的C++程序員都會寫出類似的代碼。Linus說：
“你一定使用了這種語言“好的”庫功能，如STL和Boost，它們對你的程序可能有幫助，但當它們不工作時，會引起無盡的痛苦”。
在這個程序中，我好好利用了曾是STL一部分的標準庫組件，它們作為標準的一部分已經(jīng)有十多年的歷史。它們的表現(xiàn)真的很好，在我所知道的任何編譯器中，也沒有可移植性或正確性問題。
“你會發(fā)現(xiàn)某些抽象編程模型不是很有效，但現(xiàn)在你所有的代碼都依賴于所有圍繞它的好對象模型。如果不重寫你的應用程序，那么你是無法修復它的。”
的確，盡管C++不能為我做這些事，我只有設法自己編寫程序，不使用任何抽象——沒有新的類，沒有接口，基本上完全是靠C代碼完成許多有用的類的。
但我認為這是規(guī)則而不是例外。
“換句話說，只有這樣才能做得好，效率高，系統(tǒng)級和可移植的C++最終會限制自己，但這一切在C中都是可行的。”
除非C有容器類，字符串類，類型安全I/O，以及RAII這樣的技術，這句話才會變成真的?，F(xiàn)在來看，它完全是胡說。
在現(xiàn)代C++可用之前，我可能會堅持使用一個簡單的管道來完成這個任務：
tr [:blank:] '\n' | grep -v "^$" | sort | uniq -c
事實上，我可以在編譯語言中做同樣的事。只要它們能給我一些靈活性，我想我不用成為一個偏執(zhí)狂就能明白這個事實。你對此又是怎樣看的?
作者簡介：Mark Nelson，現(xiàn)任思科公司工程師，《The Data Compression Book》的作者，《Developing Cisco IP Phone Services: A Cisco AVVID Solution》的協(xié)作者。
【51CTO.com獨家譯稿，非經(jīng)授權謝絕轉(zhuǎn)載！合作媒體轉(zhuǎn)載請注明原文出處及出處！】
【編輯推薦】
