• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>

            huaxiazhihuo

             

            回顧C++

            本人對于c++的認識,多年下來,經歷了以下幾個階段,

            1、 c++很好很強大,盲目追求運行性能,簡直巴普洛夫條件反射,貢獻了一大坨垃圾代碼;

            2、 c++的面向對象對持很垃圾,什么鬼,代碼很容易就耦合,于是迷上對象+消息發送的面向對象;

            3、 c++太復雜了,template太抽象,天外飛仙,搞不懂,二進制復用又差。整個c++就是垃圾,簡直程序設計語言里面的敗類,C語言多好啊,小巧精致簡單清晰;

            4、 使用其他語言做開發,java、C#F#、elispscheme、python、haskell、javascriptphp等等一大坨語言,感概每一種語言都比垃圾C++不要好太多,發誓不再用c++寫哪怕一行的代碼;

            5、 某一天,突然有點理解了這種語言,一切變得清晰了,原來c++也相當不錯,也可以做一些事情,看開之后,感覺開發效率也跟上來了,做同樣的事情,用c++實現不會比C#python等慢。

            相比于其他語言,c++的獨特優勢在于

            預編譯期的偽圖靈完備,這一點,好多語言還是有的,并且更超級好,比如rust,scheme

            編譯期間的C++是功能完備的解釋器,其輸出結果是正常運行的c++代碼,結合宏,可以制造很多其他語言必須在語法層面上支持的語法糖。這個解釋器的奇妙之處在于它運行于編譯期,一旦錯誤的模板代碼要進入運行期,就會出現編譯錯誤,而不需要進入運行時的代碼,即便天大錯誤,也都不要緊,而一旦這段代碼要進入運行時,那么模板錯誤就逃不過編譯期解釋器的法眼。

            生成各種內存布局的便利語法糖和自由的內存操控;不同類型的對象,只要其內存布局一致,通過強制轉換,就可按同一類型來處理,這一點作死能力,絕不被有gc的語言支持。內存的無節操玩弄,結合template,分分鐘就能仿真出來其他必須語言層面上提供的數據結構,類型安全、運行性能、易用性,一點都不遜色,好比string,委托,元組,列表,可空類型;

            C++的專有特性,raii、多繼承和全局變量。特別是全局變量,結合它的構造函數特點和類型推導,所能玩出來的豐富新花樣,其他語言很難做到。全局變量是連接運行期和編譯期的橋梁。如果沒有全局變量,本座應該不會再次對c++產生熱情。奇怪的是,至今為止,c++的基礎庫都不怎么挖掘全局變量的潛能。當然,對全局變量的使用,肯定是把它當做常量來用,全局變量有唯一的內存地址,就起到原子的作用,但它又可打包了豐富的靜態類型信息。

            以上的獨特,造就了c++層出不窮的新意,而卓越的運行性能,只是其微不足道的優點。雖然說,語言不重要,思想才重要,軟件架構才重要,但是c++所能承載的思想,以及其到達的抽象高度,的確就真的大大降低框架的復雜性,誠然,c++的基礎庫開發要面臨無窮無盡的細節糾結,其實,這也反映了c++編譯器掌控細節的能力,因此,我們又可以讓編譯器自動完成很多很多細節重復,從而大幅度地減輕代碼數量,還無損其運行性能。又由于c++完備強大的靜態類型特性,在用動態語言風格的簡潔來編寫代碼的同時,又無損其快速方便地代碼重構。筆者的基礎庫項目,幾十次大規模的重構,借助單元測試,保證了重構順利快速的完成,深感c++在重構上的便利,這些代碼,包括不到1千行卻功能完整的xml庫(還支持對象與xml數據的直接互相轉換);不到1千行卻一點都不遜色于boostspirit組合子解釋器(編譯速度卻快了很多,語法上簡潔很多,更能方便地解釋各種語法);才1千多行的異步io框架;輸入輸出,文件操作,數據庫,協程等代碼都簡潔異常,所有這些代碼都支持動態庫上的二進制復用,讓人很驚詫于c++的光怪陸離的強大。

            當然,c++的缺陷也震撼人心,

            1、 語言特性太過繁雜抽象微妙,比如template、多繼承、運算符重載、類型轉換、兼容性考慮的很多糟糕語言特性,所以對使用者的節制力要求很高,要求他們時刻清楚自己在干什么,瑣碎上的思考太多;

            2、 缺乏統一的二進制標準,基礎庫都用源代碼的形式共享,這讓原本就龜速的編譯速度更加地令人大大感動;

            3、 缺乏高標準的基礎庫,stlboost更在某些技術運用的展示上更起到很壞的影響;

            4、 缺乏某些延遲求值的機制,缺乏必要的函數式語言機制,所以c++始終就無法成為堂堂正正的現代化高級語言!

            就這樣吧。

            posted on 2017-07-15 20:07 華夏之火 閱讀(1844) 評論(2)  編輯 收藏 引用 所屬分類: c++技術探討

            評論

            # re: 回顧C++ 2017-07-17 10:55 天下

            ABI 不好搞,不過C++17如果module 標準確定的話,基本上也夠用了.
            但跨語言的ABI標準除了MS 的 COM,
            有幾個公司會去搞跨語言的ABI.因為C形式的DLL已經基本夠用了,

              回復  更多評論   

            # re: 回顧C++ 2017-07-17 11:32 華夏之火

            @天下
            C形式的dll顯然不夠用。其實,只要在c的基礎上再做多一些工作,情況就會好很多,但是委員會向來追求大而全的陋習,比如要支持虛繼承、要支持各種函數調用規定,要照顧各個編譯器的自定義等等因素,因此導致就連最基本的統一的面向對象模型都遲遲未曾出現  回復  更多評論   

            導航

            統計

            常用鏈接

            留言簿(6)

            隨筆分類

            隨筆檔案

            搜索

            積分與排名

            最新評論

            閱讀排行榜

            評論排行榜

            欧美大战日韩91综合一区婷婷久久青草 | 亚洲国产美女精品久久久久∴ | 久久乐国产综合亚洲精品| 久久美女网站免费| …久久精品99久久香蕉国产| 久久久久久精品免费免费自慰| 久久er国产精品免费观看8| 久久久久综合网久久| 大伊人青草狠狠久久| 精品国际久久久久999波多野| 久久久噜噜噜久久熟女AA片| 日日躁夜夜躁狠狠久久AV| 中文字幕日本人妻久久久免费| 国产精品成人久久久| 色综合久久无码五十路人妻| 亚洲va国产va天堂va久久| 日韩人妻无码一区二区三区久久 | 超级97碰碰碰碰久久久久最新| 久久亚洲国产成人影院网站 | 久久精品蜜芽亚洲国产AV| 久久国产精品一国产精品金尊| 久久被窝电影亚洲爽爽爽| www亚洲欲色成人久久精品| 久久久久久A亚洲欧洲AV冫| 色偷偷88欧美精品久久久| 日本WV一本一道久久香蕉| 日韩人妻无码精品久久免费一| 精品久久香蕉国产线看观看亚洲| 国产成人综合久久精品尤物| 日本高清无卡码一区二区久久| 色妞色综合久久夜夜| 亚洲国产成人久久综合碰碰动漫3d| 久久国产精品免费一区二区三区| 香港aa三级久久三级老师2021国产三级精品三级在 | 色诱久久久久综合网ywww| 一本一道久久精品综合| 久久国产AVJUST麻豆| 99久久成人国产精品免费| 亚洲精品国产综合久久一线| 俺来也俺去啦久久综合网| 亚洲а∨天堂久久精品9966|