• <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

             

            預(yù)處理之正整型

                  雖然通過(guò)一系列的奇技淫巧,讓預(yù)處理也圖靈完備一把,但是用預(yù)處理來(lái)做計(jì)算,真的很吃力不討好。因?yàn)轭A(yù)處理一開始設(shè)計(jì)出來(lái)的目的,就沒(méi)什么野心,原本就僅僅只是為了做簡(jiǎn)簡(jiǎn)單單的文本替換工作,并沒(méi)有想過(guò)要成為正兒八經(jīng)的編程語(yǔ)言,即便是最最縮水版腳本語(yǔ)言的功能要求都達(dá)不到。只是后來(lái),實(shí)在是大量要求要批量自動(dòng)生成代碼,特別是c++11之前的版本玩什么模板元編程,鋪天蓋地的要有大量相似的代碼。這些代碼用其他工具來(lái)生成,當(dāng)然形式會(huì)更加漂亮,但是始終還是用原生的預(yù)處理來(lái)做這種事情會(huì)更加的方便,否則每次修改,都要運(yùn)行一遍外部工具,都麻煩啊!本人是傾向于用預(yù)處理來(lái)生成代碼的。另外,c++11之后,的確原來(lái)很多需要宏來(lái)生成代碼的場(chǎng)合已經(jīng)不必要了,但是因?yàn)閏++11的類型推導(dǎo)能力大大加強(qiáng)了之后,發(fā)現(xiàn)又有一大波地方可以用宏來(lái)生成代碼了。并不是說(shuō)C++中的宏是必不可少之物,但是用了宏,真的可以減少很多很多的重復(fù)代碼,起碼紙面上的代碼清爽了很多。    
                      
                  預(yù)處理的原生數(shù)據(jù)類型就只有符號(hào),然后符號(hào)只支持##的并接運(yùn)算,同時(shí),預(yù)處理也能識(shí)別并接后的結(jié)果(否則,并接運(yùn)算就沒(méi)意義了),如果是宏函數(shù),就進(jìn)行調(diào)用操作,如果是宏符號(hào),就替換文本,如果什么都不是,就什么都不做,保留符號(hào)。但是這樣的弱雞類型,顯然遠(yuǎn)遠(yuǎn)不能滿足離經(jīng)叛道的碼猿需要。經(jīng)過(guò)大量的宏編程的嘗試之后,可以很肯定一點(diǎn),預(yù)處理里面只能再模擬出來(lái)一種數(shù)據(jù)類型,那就是正整數(shù),雖然通過(guò)補(bǔ)碼運(yùn)算來(lái)仿真負(fù)數(shù),但是由于預(yù)處理里面的符號(hào)不能包含減號(hào)(-)字符,當(dāng)然要花大力氣搗鼓負(fù)整數(shù)也是可以的,只是使用上也不方便也不直觀,性價(jià)比不高,基本上,必須用宏來(lái)生成代碼的地方,都可以不需要負(fù)整數(shù)的。

                 另外,預(yù)處理也沒(méi)有變量類型的概念,不要說(shuō)強(qiáng)類型,就連弱類型也不是,完全就是無(wú)類型。正整數(shù)類型的概念全靠碼猿人肉編譯器來(lái)維護(hù),一個(gè)循環(huán)的宏代碼生成一般都是來(lái)來(lái)回回也不知道調(diào)用了多少層宏調(diào)用,任何一個(gè)地方出錯(cuò),有時(shí)候是幾噸密密麻麻的中間失敗代碼(編譯器的預(yù)處理緩沖溢出,棄械投降),有時(shí)候就完全沒(méi)有輸出,沒(méi)有任何一丁點(diǎn)的提示,簡(jiǎn)直是大海撈針的找問(wèn)題。因此,在用宏循環(huán)生成代碼時(shí),必須小心翼翼,步步為營(yíng),不得不感慨,正兒八經(jīng)語(yǔ)言里面的類型真是好東西啊。

            其實(shí),數(shù)據(jù)類型并不重要,重要的是數(shù)據(jù)上能夠支持的運(yùn)算集合以及這些運(yùn)算能運(yùn)用的場(chǎng)合。
            好了,回到上文,我們用_ZPP_INC_N搞了10個(gè)數(shù),通過(guò)復(fù)制粘貼,可以把N增加到255。實(shí)際運(yùn)用中,完全足夠用了。
            #define _ZPP_INC_JOIN(_A, _B) _ZPP_INC_JOIN_IMP1(_A, _B)
            #define _ZPP_INC_JOIN_IMP1(_A, _B) _ZPP_INC_JOIN_IMP2(~, _A##_B)
            #define _ZPP_INC_JOIN_IMP2(p, res) res

            #define PP_INC(x, ) _ZPP_INC_JOIN(_ZPP_INC_, x)
            #define _ZPP_INC_0         1
            #define _ZPP_INC_1         2
            #define _ZPP_INC_2         3
            #define _ZPP_INC_3         4
            #define _ZPP_INC_4         5
            #define _ZPP_INC_5         6
            #define _ZPP_INC_6         7
            #define _ZPP_INC_7         8
            #define _ZPP_INC_8         9
            #define _ZPP_INC_9         10
            ...
            #define _ZPP_INC_255       256

            同樣的方式,再如法泡制PP_DEC,從256開始,一直遞減到0為止。對(duì)于大于256的數(shù),就不支持了,那就都是未定義操作。這樣子,通過(guò)PP_INC(n),就得到n+1;而PP_DEC(n),則是n-1。比如PP_INC(PP_DEC(9)),其結(jié)果肯定是9了。很好,這樣子,在預(yù)處理中就實(shí)現(xiàn)了自然數(shù)自增1和自減1的運(yùn)算了。另外,對(duì)于大于256的數(shù),比如512傳遞給PP_INC,就只得到一個(gè)_ZPP_INC_512的符號(hào),完全沒(méi)有任何意義。

            然后,兩個(gè)自然數(shù)是否相等的判斷,也非常重要,必須支持。但是,在此之前,要實(shí)現(xiàn)一個(gè)宏函數(shù)PP_NOT,用來(lái)判斷入?yún)⑹欠駷?。為0的話,則函數(shù)返回1,否則,就返回0。也即是:
            PP_NOT(0) == 1
            PP_NOT(23) == 0,或者 PP_NOT(var) == 0。
            記住,預(yù)處理提供給我們的原生類型就只有符號(hào)和##并接運(yùn)算,除此之外,別無(wú)他物。好像工具太簡(jiǎn)陋,能完成目的嗎?不得不佩服有些碼猿的腦洞。以下代碼是這樣運(yùn)作的,假設(shè)PP_NOT生成以下的調(diào)用形式,先不管PP_ARG1,至于符號(hào)~,是這樣子的,可以看成普通的變量名字,它就是占位符,因?yàn)轭A(yù)處理只識(shí)別逗號(hào)(,),和小括號(hào),至于其他符號(hào),完全無(wú)視,那些是C/C++編譯階段才關(guān)心的符號(hào)。
            PP_NOT(0) = PP_ARG1(~, 1, 0)
            PP_NOT(n) = PP_ARG1(_ZPP_NOT_n, 0)
            然后,讓PP_ARG1取第二個(gè)參數(shù)(碼猿的計(jì)數(shù)是從0開始的,也即是,0即是1,1即是2),就完成任務(wù)了。至于_ZPP_NOT_n是什么鬼,那個(gè)只是中間生成的臨時(shí)符號(hào),可以舍棄。我們只需對(duì)_ZPP_NOT_0做特別處理。因此,代碼可以這樣寫了。PP_PROBE()用以生成兩個(gè)入?yún)?br />#define PP_PROBE() ~, 1
            #define _ZPP_NOT_0 PP_PROBE()
            #define PP_NOT(_X, ...) PP_IS(PP_JOIN(_ZPP_NOT_, _X))
            # define PP_IS(...) PP_ARG1(__VA_ARGS__, 0)

            這樣子之后,顯然PP_NOT(n)就可以變成PP_ARG1(_ZPP_NOT_n, 0)的形式了。PP_NOT不是只需一個(gè)入?yún)幔繛楹魏竺孢€要帶省略號(hào),純粹是為了后面各種變態(tài)的運(yùn)用,取悅編譯器。已經(jīng)用宏來(lái)寫代碼了,就不必再遵守什么清規(guī)戒律,只要能完成任務(wù)就行了。

            至于PP_ARG1的實(shí)現(xiàn),就很簡(jiǎn)單了,如下所示,
            #define PP_ARG0(_0, ...) _0
            #define PP_ARG1(_0, _1, ...) _1
            #define PP_ARG2(_0, _1, _2, ...) _2

            然后通過(guò)兩次取反的函數(shù),再補(bǔ)上函數(shù)PP_BOOL,如果入?yún)?gt;0,就返回1,否則返回0,類似于整型到bool的強(qiáng)制類型轉(zhuǎn)換。
            #define PP_BOOL(_X, ...) PP_NOT(PP_NOT(_X))

            有了這些的鋪墊之后,要比較兩個(gè)自然數(shù)是否相等,就簡(jiǎn)單了。其實(shí)沒(méi)什么神秘的,就是針對(duì)從0到255,重復(fù)256個(gè)以下形式的#define語(yǔ)句,
            #define    _ZPP_0_EQUALS_0        PP_PROBE()
            #define    _ZPP_1_EQUALS_1        PP_PROBE()
            #define    _ZPP_2_EQUALS_2        PP_PROBE()
            ...
            #define PP_EQUALS(x, y) PP_IS(PP_CONCAT4(_ZPP_, x, _EQUALS_, y))
            PP_EQUALS就是將入?yún)⒉⒔映蒧ZPP_x_EQUALS_y的形式,只要x和y相同,也即是說(shuō),它們?cè)谏厦娴谋砀裰校敲矗览砭腿缤琍P_NOT的實(shí)現(xiàn)那樣,最后結(jié)果就是1了。其實(shí),預(yù)處理中沒(méi)有判斷這種玩意,只有表格,只有并接,只有查表。所謂的圖靈完備,說(shuō)白了,沒(méi)有玄虛的,就是建表,然后查表。對(duì)相等比較取反PP_NOT,自然就得到不相等的判斷函數(shù)。
            #define PP_UN_EQUALS(x, y) PP_NOT(PP_IS(PP_CONCAT4(_ZPP_, x, _EQUALS_, y)))
            再次建表,就可以得到bool運(yùn)算的函數(shù),或與
            #define PP_OR(a,b) PP_CONCAT3(_ZPP_OR_, a, b)
            #define _ZPP_OR_00 0
            #define _ZPP_OR_01 1
            #define _ZPP_OR_10 1
            #define _ZPP_OR_11 1

            #define PP_AND(a,b) PP_CONCAT3(_ZPP_AND_, a, b)
            #define _ZPP_AND_00 0
            #define _ZPP_AND_01 0
            #define _ZPP_AND_10 0
            #define _ZPP_AND_11 1

            再準(zhǔn)備一張表格,將字節(jié)映射到8個(gè)二進(jìn)制位。
            #define _ZPP_BINARY_0    (0, 0, 0, 0, 0, 0, 0, 0)
            #define _ZPP_BINARY_1    (0, 0, 0, 0, 0, 0, 0, 1)
            #define _ZPP_BINARY_2    (0, 0, 0, 0, 0, 0, 1, 0)
            #define _ZPP_BINARY_3    (0, 0, 0, 0, 0, 0, 1, 1)
            #define _ZPP_BINARY_4    (0, 0, 0, 0, 0, 1, 0, 0)
            ...
            然后通過(guò)模擬計(jì)算機(jī)組成原理里面的加減乘除的原理,就可以實(shí)現(xiàn)四則運(yùn)算了。對(duì)了,整個(gè)預(yù)處理庫(kù)的代碼都在壓縮包上,功能比boost的預(yù)處理庫(kù)強(qiáng)多了,但是代碼卻少了很多,也容易理解多了,所有代碼在vs下面正常運(yùn)行,其他平臺(tái)還沒(méi)有測(cè)試。代碼包:/Files/huaxiazhihuo/preprocessor.rar

            posted on 2017-07-04 14:21 華夏之火 閱讀(778) 評(píng)論(0)  編輯 收藏 引用 所屬分類: C++代碼自動(dòng)生成

            導(dǎo)航

            統(tǒng)計(jì)

            常用鏈接

            留言簿(6)

            隨筆分類

            隨筆檔案

            搜索

            積分與排名

            最新評(píng)論

            閱讀排行榜

            評(píng)論排行榜

            国产精品九九久久免费视频 | 久久精品天天中文字幕人妻| 久久精品国产亚洲av瑜伽| 精品国产91久久久久久久| 国产精品久久久久久影院| 九九99精品久久久久久| 久久伊人精品青青草原高清| 成人国内精品久久久久影院VR| 四虎国产永久免费久久| 久久亚洲中文字幕精品一区四| 午夜精品久久久久成人| 久久久久久久久波多野高潮| 亚洲国产另类久久久精品黑人| 久久综合综合久久综合| 久久免费精品视频| 久久精品二区| 久久精品国产亚洲αv忘忧草 | av无码久久久久久不卡网站| 国产日产久久高清欧美一区| 免费观看成人久久网免费观看| 国产精品久久久久久久午夜片| 亚洲国产婷婷香蕉久久久久久| 久久亚洲AV成人无码| 97久久精品无码一区二区天美 | 国产精品亚洲综合久久| 精品久久久无码人妻中文字幕豆芽 | 国产成人精品久久| 久久成人精品视频| 久久这里有精品| 欧美777精品久久久久网| 欧美国产成人久久精品| 国产精品99久久久久久人| 欧美精品福利视频一区二区三区久久久精品 | 热综合一本伊人久久精品| 亚洲欧美日韩久久精品第一区| 国产精品美女久久久| 久久频这里精品99香蕉久| 嫩草影院久久99| 国产麻豆精品久久一二三| 久久这里有精品| 日日狠狠久久偷偷色综合96蜜桃|