• <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++用成動態(tài)語言,或者函數(shù)式語言,以達到快速開發(fā)的目的,并且在需要優(yōu)化的情況下,又能夠方便快速的優(yōu)化。現(xiàn)在事務(wù)太多,不知道何時能填坑

            宏的圖靈完備,用宏生成代碼,特別是反射,模式匹配,實在必不可少,以至于宏可以與c++的繼承、template、exception等基本組件并列的重要必不可少的補充手段

            最小巧方便使用的單元測試框架,比gtest,cppunit要好用很多

            自定義內(nèi)存管理器,stl中的allocator是作為模板參數(shù)來傳遞,嘗試以tls來傳遞allocator參數(shù),當然,必須相應(yīng)的各種容器都要重寫,修改其缺省構(gòu)造函數(shù),拷貝復(fù)制移動拷貝,給元素分配內(nèi)存釋放內(nèi)存等。對了,還有各種容器的反射信息。每種類型的template的容器都有一個typeinfo對象,具體的容器又有自己獨一的typeinfo對象

            完善完備的reflection,也就是,其他language能夠做的反射的事情,這里只要愿意,也可以做到,非侵入式,可以給int,double等基本類型添加反射,給template類型的也添加反射信息,保證每種類型的反射對象是唯一的;

            史上功能最完善的fmt的實現(xiàn),非template,當然,外層還需要variadic來包裝,以類型信息。類型安全,緩沖安全,高效,通用。通用的意思是,可以fmt到文件,日志,字符串,文本框控件中;類型安全的意思是,可以是所有的類型都可以fmt,只要該類型實現(xiàn)了相應(yīng)的接口,但是,這種接口是非侵入式的,通過模板特化。高效的意思是合sprintf系列一樣。調(diào)用的時候如下:
            fmt(text, "%s %s %d ", 20, 17.5, 'a'); //故意寫錯%s的,在這里,%s為通用符號
            fmt(file, "{%s-}",{1, 2, 3}); //輸出 1-2-3到文件中,也即是能夠fmt容器對象,橫線-為容器對元素的分隔符

            帶有切片功能的數(shù)組,此數(shù)組類型還支持子類型數(shù)組到基類型數(shù)組的隱式轉(zhuǎn)換,也即是需要用到基類型數(shù)組的參數(shù),子類型數(shù)組都可以適應(yīng)

            haskell的map,filter,fold算法在C++下的方便靈活組合性的改造,使用時,就好像C#的linq那么爽快,當然,沒有l(wèi)ambda的參數(shù)自動推導(dǎo),畢竟還不如

            stackless協(xié)程

            c++下的monad

            wpf的依賴屬性在c++下的實現(xiàn),gui框架的不可缺少的要素

            tupple的功能擴展,通過宏,不需要寫類型,用起來就好像函數(shù)式語言原生的那么爽的可能

            好像haskell或者f#那樣的模式匹配的結(jié)構(gòu)體

            C++下完完全全實現(xiàn)狗語言的那種鴨子類型的接口

            面向?qū)ο蟮纳钊胩接懀瑢τ谄簌Z或者雞是一種鳥,繼承了鳥,但是沒有繼承了會飛的接口,在編譯期就能報錯,在運行期也不能對其找到會飛的接口

            具體類,基本類型,沒有虛函數(shù),但是又能實現(xiàn)接口的方式,是實實在在的接口,里面有純虛函數(shù),也即是非侵入式的實現(xiàn)接口,上面宇宙最強悍的fmt就是用到這里的技術(shù)

            vistor模式和抽象工廠的解耦合,或者又叫,multi dispatch

            類型安全的消息,一條消息就代表了一種函數(shù)調(diào)用,不是win32的那種一點也不安全的類型系統(tǒng),然后可以向任何類發(fā)送消息,動態(tài)添加消息的反應(yīng),消息隊列,消息和消息參數(shù)的保存,actor,command模式,redo或undo的輕松實現(xiàn),消息廣播

            空基類優(yōu)化的運用,除了多繼承(ATL)或者內(nèi)嵌類(MFC),還有其他方式,那是以組合方式,通過少量的模板和少量的宏,通過搭配組裝(多繼承空基類)各種基類,就能完成一個com組件

            消息系統(tǒng)的構(gòu)建,gui框架的編寫

            ........

            博大精深的c++!只是想說,上面的一切,在C++下全部都是可行的,當然,宏,template,多繼承必須大用特用,只是,奇妙的是,主類的內(nèi)存布局卻很干凈,甚至可以沒有虛函數(shù)
            不知道有生之年能否填完坑,以之為勵吧!
            c++的同學們也充分發(fā)揮想象力吧,太多的奇技淫巧了。

            posted on 2016-05-09 20:36 華夏之火 閱讀(1354) 評論(8)  編輯 收藏 引用 所屬分類: c++技術(shù)探討

            評論

            # re: 挖坑,有空填坑 2016-05-09 21:21 jigloo

            我仿佛看了一個一只巨大的人形自走嘴炮。
            http://eznewlife.com/focus_photos/100/2012_05_0131.jpg  回復(fù)  更多評論   

            # re: 挖坑,有空填坑 2016-05-10 08:10 呵呵

            你牛B,宏是禍患的根源,大量使用宏等于自尋煩惱。哪個軟件宏用的比例大,哪個Bug無數(shù),后期維護就明白了。  回復(fù)  更多評論   

            # re: 挖坑,有空填坑 2016-05-10 10:03 華夏之火

            老朽也排斥宏啊,但是,c++又沒有反射,沒有模式匹配,沒有原生的tupple支持等等,在用這些好東西的時候,不用宏,就要寫大量的重復(fù)代碼。比如,f1函數(shù)返回值為tupple<int,string>。與其寫:auto tt = f1();auto num=get<1>(tt);auto text=get<2>(tt);就不如用宏自動生成這三行代碼,TUPPLE_VALUES(num,text,f1)  回復(fù)  更多評論   

            # re: 挖坑,有空填坑 2016-05-10 16:51 Richard Wei

            歡迎回來...  回復(fù)  更多評論   

            # re: 挖坑,有空填坑 2016-05-10 18:20 華夏之火

            @Richard Wei
            一直都想回來的,不過,可能也來不了,很多代碼要寫,并且還不是用C++開發(fā)。很久沒用C++了  回復(fù)  更多評論   

            # re: 挖坑,有空填坑[未登錄] 2016-05-10 20:47 Arthur

            嗯,坑挖好了就可以把自己埋了...
            記得挖深點哦  回復(fù)  更多評論   

            # re: 挖坑,有空填坑[未登錄] 2016-05-11 18:16 春秋十二月

            你主要是做哪方面的開發(fā)?  回復(fù)  更多評論   

            # re: 挖坑,有空填坑 2016-05-11 19:12 華夏之火

            @春秋十二月
            和c++無關(guān)的事情。C#,java,python,javascript等,主要還是C#  回復(fù)  更多評論   

            導(dǎo)航

            統(tǒng)計

            常用鏈接

            留言簿(6)

            隨筆分類

            隨筆檔案

            搜索

            積分與排名

            最新評論

            閱讀排行榜

            評論排行榜

            久久久久亚洲AV成人网| 久久电影网| 国内精品久久久久久99蜜桃| 久久久久久久女国产乱让韩| 亚洲va中文字幕无码久久| 国产精品女同久久久久电影院| 国产成人精品久久免费动漫| 久久人人超碰精品CAOPOREN| 2021国产精品午夜久久| 久久99国产精品尤物| 久久精品国产72国产精福利| 久久久久亚洲AV无码永不| 久久精品免费网站网| 人妻无码久久一区二区三区免费| 国产一区二区精品久久| 久久经典免费视频| 99久久精品免费看国产一区二区三区| 精品一二三区久久aaa片| 久久精品人妻一区二区三区| 久久久久久免费一区二区三区| 亚洲七七久久精品中文国产| 久久国产精品久久久| 看久久久久久a级毛片| 久久精品视频一| 青青草原综合久久大伊人导航 | 精品久久久无码人妻中文字幕| AAA级久久久精品无码区| 精品久久无码中文字幕| 久久精品国产亚洲AV香蕉| 欧美激情精品久久久久久久九九九| 精品少妇人妻av无码久久| 久久综合给合久久狠狠狠97色| 午夜视频久久久久一区| 久久国产精品一区| 久久国产福利免费| 久久99精品久久久久久9蜜桃 | 精品久久久久久99人妻| 99久久超碰中文字幕伊人| 亚洲国产精品高清久久久| 日韩人妻无码一区二区三区久久| 亚洲中文字幕久久精品无码APP |