程序師世界是廣大編程愛好者互助、分享、學習的平台,程序師世界有你更精彩!
首頁
編程語言
C語言|JAVA編程
Python編程
網頁編程
ASP編程|PHP編程
JSP編程
數據庫知識
MYSQL數據庫|SqlServer數據庫
Oracle數據庫|DB2數據庫
 程式師世界 >> 編程語言 >> C語言 >> C++ >> 關於C++ >> 用C設計 用C++編碼

用C設計 用C++編碼

編輯:關於C++

《不得不看的兩次從C++回歸C的高手評論C++》中先是提了一下所謂C++帶來的思想包袱(文言文曰“心智包袱”)問題,然後重重地引用了Linus的話:“關鍵是設計”,其實他是在暗示:好的設計C同樣能做出來,不勞C++大駕;而C++一旦出面,就要讓人背上額外的思想包袱。

我明確地表個態,在系統級程序設計中,事實就是這樣的。

別小看這個思想包袱,大部分,甚至絕大部分C++程序員過不了這一關。相反,做系統級開發,C是幾乎沒有思想包袱的語言,說白了就是刺刀見紅,你想要啥你就去寫啥,它給你的不多也不少,沒什麼干不了,也沒什麼非讓你背著不可。

我早在N年前就發現自己寫程序速度慢,我當時對STL遠比周圍人熟悉,照例說長纓在手,應該效率很高才對。結果發現不是,寫程序的時候特別沒自信,總在想:“這樣固然是可以work了,但恐怕有更好的方案吧!會是什麼呢?加個模板參數試試?要麼抽象出一個基類?做一個bridge模式?那麼Ownership的問題怎麼解決?誰來負責回收內存呢?移植一個boost::shared_ptr過來吧!可多線程情況下會不會拖慢速度呢?應該不會,可是會碰到循環引用的情況。要麼在中間搞一個weak_ptr把循環鏈斷開?哎呀!不行不行,太復雜,別人也理解不了。還是先這樣吧!能work就行。”就這樣,兜了一個圈子回來。有的時候,這個圈子不是純柏拉圖式的,我會真的實現不少“優化”設計來比對,那個時間啊!花花的就耗在裡面了。有的時候確實會獲得一些改進,但是多數時候是得不償失,旁邊那些在我看來連C都只是一知半解的家伙采用“CtrlC-CtrlV-Modify-Debug”方法,早就沖到我前頭去了。這就是“心智包袱”的威力。

最近幾年沒怎麼用C++寫程序,業余時間倒是別的語言用了好幾種。大概是體會到這些語言的某些好處之後,對C++就能看得更客觀一些了,也琢磨了一下,如果自己有朝一日重新跑回去寫C/C++,我會怎麼干?畢竟現在C++程序員全球緊缺,工資越來越高,這個問題還是有其現實意義的。正好跟chensh 聊了一會兒,兩個人的看法一致,就是采取“ C + Concreate Class + STL”的風格。說白了就是用C來設計,用C++來編碼。

這裡面的道理是這樣的,反正現在C和C++都是來做系統級開發,那些華麗的抽象機制用不上,思考解決方案的時候,就以C的方式。注意,C也是可以做基於對象甚至面向對象甚至組件級別的設計的,但是在C的層面上思考問題,設計能夠更精益(lean,現在這是個時髦詞),更輕便,更直接。當你構思的設計方案出來以後,如果其中有些部分,恰好是C++現成做好了,而且使用C++又可以提高開發效率,也沒什麼明顯的副作用,那麼就用C++來做相應的部分。比如,COM原來設計的時候就是在C基礎上做的,設計的時候發現實際上跟C++實現多態的的vptr + vtable是吻合的,所以後來就主要用C++來做COM開發。事實上,為了適應COM開發的需要,微軟直接改了C++編譯器。很顯然,微軟是首先構思好的設計,然後讓C++去適應這個設計。而後來很多C++程序員,是讓設計去適應C++的那些語言機制,在系統開發中,這個叫做本末倒置。當然這樣的事情在應用級別上就不是那麼離譜。

實際上回頭看看C++早期的歷史,最早C++就是把一些C中常用的patterns內置到語言裡而出現的,早期它曾經有效地提高了開發效率。今天應該回頭去尋找這種精神。

我支持STL是基於同樣的理由。很多時候,你從C出發得到的設計,也無非就是STL已經實現得很好的東西。在這個時候,當然可以用STL。尤其是那些算法,針對C array也是適用的,用accumulate求和,用transform映射,用adjacent_find尋找相等的毗鄰項,用lower_bound和equal_range做二分查找等等,這不是比手寫要爽多了嗎?當然,使用STL,還是必須熟悉其背後的機理,沒有這個底子,還是規規矩矩用C算了。

  1. 上一頁:
  2. 下一頁:
Copyright © 程式師世界 All Rights Reserved