淺薄與偏見駁“C語言已經死了”

2019-11-17 05:49:09

字體：大中小

來源：轉載

供稿：網友

　　現在，有很多C/C++程序員總是自命不凡，看不起其他開發人員。其實，或許別人更看不起他呢!　　>> 有偏見的永遠只是個體，而不是群體。作者加了后面那句，無疑證實有偏見的不是C/C++程序員，而正是他自己。

　　學生時代，我也曾醉心于C/C++，但時至今日，始終無法寫出無懈可擊的C++代碼，所以我始終認為我不會C/C++。這些年，我一直在尋找編寫C++代碼的最佳模式。但是，老實說，我還沒有見到過哪個稱得上高手的C++程序員，也沒有見到過寫得Very good的C/C++代碼。C/C++代碼總是丑陋不堪，BUG叢生!　　>> 這段話更加荒謬了。沒見過優秀的C/C++代碼? C++標準庫(STL)如此優雅。況且，有那么多經典的C/C++開源作品，以及無意之中泄漏的Windows NT核心源碼，哪一樣不是絕世之作?我為作者淺陋感到難過。　　我用C語言編程已經超過20年了。我寫過C語言的編譯器、C語言的調試器、用C開發的其他語言、java、C#等)均把這個解決方案強加給程序員，這一定程度上來說減輕了程序員的負擔，但是也同時約束了程序員的主觀能動性。"分配內存和釋放內存在C語言中都是很慢的"?不知道作者從哪里獲得的結論?！　?、多線程　　我過去是喜歡C語言的，真的。直到我開始用C開發并維護多線程的服務器。在為連接相沖突的線程保護數據方面，C語言沒有為程序員提供那怕一點點的幫助。你在使用單線程的日子里獲得的每一個直覺、經驗，用在多線程的時候都是錯誤的。至少JAVA有表示同步的要害字和備有證實文件(但是是個很希奇的文件)的記憶體，但即使是這樣，除非你使用新的javax.concurrent，否則也只能在那些巨大的平行擺放的機器們面前崩潰?；氐紺語言上：在模擬生產的環境下，堅持一個星期在數據中心調試一個死鎖(這事真的發生過)。而JAVA卻只需要Ctrl+Break!天哪!!!　　>> C/C++語言本身確實沒有太多MultiThead的支持，這種情況在C++0x出來后可望改變。但是，請記住C/C++永遠傾向于你使用成熟的庫來解決問題。　　3、指針　　指針太難以控制了，太陰險了;我甚至沒有委婉一點的方式去形容它。我生命中每年都有幾個月被用來調試那些希奇的指針問題。我過去經常努力獲取所有的訣竅，比方說難以理解的構成符、聯合體和偏移量，以及重用最后兩位做標記，還有所有其他的訣竅。但我發現這么做根本不值得。其他語言的靜態引用就可以解決了?！　?gt;> 指針是C/C++過于靈活的體現。使用指針的代碼可以寫得很丑陋，但一樣可以很優雅?！@一點上用何種語言不會有區別。我相信，可以寫出優雅的Java代碼，那么也一定可以寫出同樣優雅的C/C++代碼。而反之則未必(因為有些C++某些范式是Java所不能支持的)。C/C++語言中的選擇太多，這的確是令人困惑的，但不見得是劣勢。我對C/C++程序員的建議是，多了解和使用C++標準庫，而不是過于糾纏指針相關的細節。
　　4、過早的優化　　說到訣竅，你是否曾經浪費腦細胞去研究究竟*p++是不是比p[i]快?你是否曾經花時間去試著做點變化來代替乘法，或者去嘗試使循環中的倒置運行更快的方法?還在為傳遞一個參數的速度和反對添加結構，并且傳遞它的速度一樣而苦惱不已?停吧!算法是速度的要害，程序員的水平決定了他會使用那些算法。知道這一點能讓你的程序更好，更快一點并且讓你的腦袋少扭幾個筋。好吧，有一些例子也許可以這樣做的……不，你就別那么做就行了!　　>> 算法優化是程序設計的要害。但是通常情況下，所有語言(包括C/C++)的程序員研究的是要害路徑的優化。研究*p++是不是比p[i]快?我相信這是標準庫的實現者要考慮的事情。所不同的是，C/C++程序員也可以和標準庫的作者一樣去考慮這些細節，而其他語言的程序員被剝奪了這個權利?！　≌f到優化，話題就多了。我曾經向C#的Dictionary中插入了1億條整數(從1萬多個文本文件中讀入)，結果發現程序運行了整整一個下午仍然沒有完成。而我改用C++的std::map，20分鐘就搞定了。再試試對50萬條自定義的結構體數據進行排序，我相信你和我一樣，會深深喜歡上C++的的高效而優雅?！　?、測試　　你最喜歡的C的單元測試的工具是哪個?嗯…一個也想不到?單元測試一定是一點也不重要，是吧?或者是太麻煩了，很難跟上進度，浪費時間。你可以把這個時間用到更加有用的事情上，讓它只占用工作時間的1%，那還比較合適?；蛘咴跀祿行?，通過優化的沒有標記的圖形來調試這個僅僅由100個同時在線使用者引起的問題?！　?gt;> C++的測試工具，作者居然一個都想不到，我只能猜想可能他是比較喜歡自己制造輪子的那一類。和JUnit對應的CppUnit，難道也想不到?提起CppUnit，我以前用它進行單元測試，但從實現架構上說，我認為它繼續了Java代碼的臃腫。我在WINX中提供了一個Mini版本的CppUnit，代碼量大概只有幾百行，功能絕不比CppUnit弱。(要了解WINX，請看這里)?！　∥冶緛響摾^續再說一些原因的，但是5個現在就足夠了;說完這些，現在感覺好點了。C以前是非常棒的…那是在1984年的時候。直到今天，那些用C寫的新代碼都讓我感到驚喜…假如你讓我比較的話，我覺得C++只是比C稍微好點。假如你想要學些老一點的語言，不妨嘗試Forth，List，或者APL。這些老式的語言起碼能教會你，用不同的而且優雅的方式去思考你的程序。　　>> 新生的語言，必然會在吸收舊的語言上基礎上進行改進?？匆粋€語言的生命力，并不在于看它某些地方存在的不足。事物會發展，并趨于完善。相信C++0x出來后，C/C++語言又將獲得新的生命力。單看Java、C#等幾個新一代的語言，其中有如此多的C++烙印，就證實了C/C++的影響是巨大的。動不動說一門語言死了，是一種淺薄。

上一篇：Pure C++：泛型編程：模板特殊化

下一篇：并非偏見也駁“駁‘C語言已經死了‘”