青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品

loop_in_codes

低調(diào)做技術(shù)__歡迎移步我的獨(dú)立博客 codemaro.com 微博 kevinlynx

代碼自動(dòng)生成-宏遞歸思想

Macro Recursion
author: Kevin Lynx

Preface

    本文可能是<代碼自動(dòng)生成-宏帶來(lái)的奇技淫巧>的續(xù)寫(xiě)。我盡力闡述如何讓宏遞歸(或者說(shuō)重復(fù))地有規(guī)律地產(chǎn)生一
些符號(hào),而讓我們少寫(xiě)很多重復(fù)代碼,也許這些代碼只有那么一點(diǎn)點(diǎn)的不同。將這項(xiàng)小技巧用于底層庫(kù)的編寫(xiě),會(huì)讓代碼
看起來(lái)干凈不少,同時(shí)文件尺寸也會(huì)驟然下降。


Problem


    如果你曾經(jīng)寫(xiě)過(guò)functor,那么你肯定對(duì)某些代碼進(jìn)行粘貼復(fù)制然后修改。更讓人郁悶的是,這些代碼基本是一樣的。
例如,一個(gè)典型的functor可能為:

    template <typename Prototype>
    
class functor;
    template 
<typename R, typename P1>
    
class functor<R(P1)>;
    template 
<typename R, typename P1, typename P2>
    
class functor<R(P1,P2)>;


    //好,接下去你可能厭煩了,可能會(huì)復(fù)制一個(gè)帶有兩個(gè)參數(shù)的functor,然后修改為處理3個(gè)參數(shù)的。
    這只是一個(gè)很簡(jiǎn)單的問(wèn)題。宏不是c++里的東西,本文自然也不是討論各種花哨的模板技術(shù)的。如果我之前那篇關(guān)于
宏的文章只是讓你去分析問(wèn)題以及更深層次地認(rèn)識(shí)宏,那么現(xiàn)在我將分享我的這部分思想給你。
    關(guān)于上面的問(wèn)題,我們期待得到這樣的解決方案:

    template <typename R, DEF_PARAM( 2 )>
    
class functor<R( DEF_ARG( 2 ) )>;


    那么,它將自動(dòng)生成:

    template <typename R, typename P1, typename P2>
    
class functor<R(P1,P2)>


    也就是說(shuō),DEF_PARAM(n)這個(gè)宏將根據(jù)n值自動(dòng)生成一串符號(hào),例如DEF_PARAM(2)就生成typename P1, typename P2。
同樣,DEF_ARG(n)也會(huì)根據(jù)參數(shù)生成類似于P1,P2,...,Pn的符號(hào)串。

思考

    仔細(xì)思考下,我們可以看出DEF_PARAM和DEF_ARG這樣的宏具有一種遞歸的特性(其實(shí)說(shuō)成重復(fù)可能更合適):每次展
開(kāi)的內(nèi)容基本一樣,不斷調(diào)用自身直到遇到終止條件。
    那么,我們的目標(biāo)鎖定于,用宏來(lái)實(shí)現(xiàn)遞歸。


Pre-Implement

    在開(kāi)始之前,我需要告訴你一些基本的東西:
    在閱讀一個(gè)宏時(shí),你最好按照預(yù)處理的處理方式去逐個(gè)展開(kāi)。當(dāng)我說(shuō)到展開(kāi)時(shí),我的意思是把宏替換為宏體。預(yù)處理器
展開(kāi)宏的過(guò)程大致為:如果宏參數(shù)也是個(gè)宏,那么先將宏參數(shù)全部展開(kāi),再展開(kāi)該宏;這個(gè)時(shí)候會(huì)掃描展開(kāi)后的宏,如果
遇到其他宏,則繼續(xù)展開(kāi)。例如有一下宏:

 

#define PI 3.14
#define MUL_PI( n ) n * PI
#define TWO 2


    當(dāng)我們寫(xiě)下MUL_PI( TWO )時(shí),預(yù)處理發(fā)現(xiàn)MUL_PI的參數(shù)TWO 是個(gè)宏,那么先將TWO展開(kāi)得到2,然后將2放進(jìn)宏體展開(kāi)
得到 2 * PI;預(yù)處理器對(duì) 2 * PI 進(jìn)行掃描,發(fā)現(xiàn)還有宏P(guān)I,于是對(duì)PI做展開(kāi),得到 2 * 3.14。這個(gè)過(guò)程是遞歸的。
    但是也有例外,如果MUL_PI對(duì)宏參數(shù)進(jìn)行了#或者##,那么該宏參數(shù)不會(huì)被展開(kāi)。(參見(jiàn)以前那篇文章吧)
    任何時(shí)候,你可以通過(guò)以下宏去查看某個(gè)宏展開(kāi)后的樣子,可以方便你調(diào)試你的宏:

#define TO_STRING( x ) TO_STRING1( x )
#define TO_STRING1( x ) #x 


    (為什么要寫(xiě)個(gè)TO_STRING1,因?yàn)檫@是為了讓x充分展開(kāi),避免上面提到的那個(gè)例外)   

    其他規(guī)則我會(huì)在文中需要的地方提出來(lái)。
實(shí)現(xiàn)

    就像大部分介紹遞歸函數(shù)時(shí)候給的例子,這里我也將階乘作為例子。考慮如下典型的階乘函數(shù):

    int fac( int n )
    
{
        
if( n == 1 ) return 1;
        
return n * fac( n - 1 );
    }
 


    其核心部分在于 n * fac( n - 1 ),我們假設(shè)我們的宏也可以寫(xiě)成這樣的的形式:

    #define FAC( n ) n * FAC( n - 1 )


    但是這樣的宏是有問(wèn)題的:
    當(dāng)宏被展開(kāi)時(shí),如果遇到了自身,那么將被處理為一般符號(hào),例如展開(kāi)FAC( 3 )時(shí),會(huì)遇到 FAC( 2 ),那么就把FAC
( 2 )中的FAC當(dāng)成了一搬符號(hào)。
    這樣的限制注定了我們無(wú)法讓宏真正地調(diào)用自身來(lái)實(shí)現(xiàn)遞歸。于是,我們不得不寫(xiě)下以下丑陋的符號(hào),從而去模擬遞
歸的每一次符號(hào)調(diào)用:

#define FAC_1( n ) 1
#define FAC_2( n ) n * FAC_##(n-1)( n - 1 )
#define FAC_3( n ) n * FAC_##(n-1)( n - 1 ) 


    這系列宏有點(diǎn)別扭(如果你足夠細(xì)心),因?yàn)槲覀兠黠@知道FAC_2返回的將是2,而FAC_3返回的當(dāng)時(shí)6。我們這里只是
模擬,同樣,這使得我們可以把FAC_1作為遞歸的終止條件。
    我們的預(yù)想是,當(dāng)調(diào)用FAC_3時(shí),它把n-1的值2合并到FAC_中,從而調(diào)用FAC_2,以此類推。
    但是這依然有問(wèn)題,編譯器會(huì)提示‘找不到符號(hào)FAC_’。導(dǎo)致這個(gè)問(wèn)題的原因在于:宏展開(kāi)只是單純的字符替換,是我們
想太多了,預(yù)處理器并不會(huì)去計(jì)算( n - 1 )的值是多少,也就是我們無(wú)法得到FAC_2這個(gè)宏。

    所以,F(xiàn)AC_3( 3 ) 會(huì)被初次替換為 3 * FAC_(3-1)( 3 - 1 )。這個(gè)時(shí)候編譯器就把FAC_當(dāng)成了一個(gè)普通符號(hào)。我們可以
自己定義個(gè)FAC_來(lái)證明這一點(diǎn):

 

#define FAC_( n ) T 

 

    那么,F(xiàn)AC_3( 3 )就被替換為 3 * T(3-1)( 3 - 1 )。

    解決這個(gè)問(wèn)題的辦法關(guān)鍵在于,讓預(yù)處理器自動(dòng)計(jì)算出( n - 1 )。記住,我們解決問(wèn)題的唯一辦法是:字符替換。
所以,我們可以寫(xiě)下如下代碼:

 

#define DEC_1 0
#define DEC_2 1
#define DEC_3 2 

#define DEC( n ) DEC_##n 

 

    通過(guò),DEC( n )這個(gè)宏,我們可以獲取到一個(gè)( n -1 )的數(shù)。例如,DEC( 3 )被替換為 DEC_3,繼續(xù)替換為 2。

    于是,我們新的FAC系列宏變?yōu)椋?

 

#define FAC_1( n ) 1
#define FAC_2( n ) n * FAC_##DEC( n )( n - 1 )
#define FAC_3( n ) n * FAC_##DEC( n )( n - 1 ) 

 

    不好意思,這樣依然是不正確的!預(yù)處理器直接把FAC_和DEC( n )連接成符號(hào)了,而不是單個(gè)地先處理他們,最后再
合并他們。

    OK,先解決這個(gè)問(wèn)題:先處理FAC_和DEC( n ),再合并他們,而不是先合并他們。要解決這個(gè)問(wèn)題,可以通過(guò)第三個(gè)宏
來(lái)實(shí)現(xiàn):

 

#define CHR( x, y ) x##y 

 

    作為連接兩個(gè)符號(hào)為一個(gè)符號(hào)的宏,這個(gè)宏顯然是不正確的,因?yàn)楹暾归_(kāi)還有個(gè)規(guī)則:如果宏體對(duì)宏參數(shù)使用了#或##,
那么宏參數(shù)不會(huì)被展開(kāi),也就是說(shuō):如果CHR( FAC_, DEC( 3 ) 那么得到的只會(huì)是 FAC_DEC( 3 )。通常情況下我們是
再寫(xiě)個(gè)宏:

 

#define CHR( x, y ) CHR1( x, y )
#define CHR1( x, y ) x##y 

 

    從而可以保證在正式連接x和y前,x和y都被完全展開(kāi)。

    這個(gè)時(shí)候,我們的FAC系列宏變?yōu)椋?

 

#define FAC_1( n ) 1
#define FAC_2( n ) n * CHR( FAC_, DEC( n ) )( n - 1 )
#define FAC_3( n ) n * CHR( FAC_, DEC( n ) )( n - 1 ) 

 

    結(jié)果呢?結(jié)果還是有問(wèn)題。= =
    我們假設(shè)CHR( FAC_, DEC( n ) )已經(jīng)真的按我們預(yù)想展開(kāi)為 FAC_2了,那么FAC_3( 3 )會(huì)被展開(kāi)為什么呢?
被展開(kāi)為 3 * FAC_2( 3 - 1 )。這是錯(cuò)誤的,傳給 FAC_2 的參數(shù)是 3 - 1就意味著錯(cuò)誤。我們又臆想預(yù)處理器會(huì)
幫我們計(jì)算 3 - 1的結(jié)果了。我們必須保證傳給 FAC_2的參數(shù)是個(gè)數(shù)字2。解決這個(gè)問(wèn)題的辦法就是通過(guò)DEC(n)宏。

   于是,F(xiàn)AC系列宏變?yōu)椋?

 

#define FAC_1( n ) 1
#define FAC_2( n ) n * CHR( FAC_, DEC( n ) )( DEC( n ) )
#define FAC_3( n ) n * CHR( FAC_, DEC( n ) )( DEC( n ) ) 

 

    這個(gè)時(shí)候,F(xiàn)AC_3( 3 )將會(huì)被替換為:3*2*1。這就是我們要的結(jié)果。

In practice

    以上只是向你展示一個(gè)過(guò)程,用宏去計(jì)算階乘,就像用模板去計(jì)算階乘(模板元編程)一樣,只是一個(gè)用于展示的東西,
沒(méi)有什么實(shí)際價(jià)值。接下來(lái)我們開(kāi)始有實(shí)際的工作,完成之前的預(yù)想:

 

template <typename R, typename P1, typename P2, typename P3>
class functor<R (P1, P2, P3)> 

 

    直接:

 

template <typename R, PARAM( 3 )>
class functor<R (ARG( 3 ))> 

 

    先考慮PARAM宏,該宏的任務(wù)就是生成類似于:typename P1, typename P2, typename P3這樣的符號(hào)。我們假象它每一次
遞歸都生成 typename Pn, 的字符串,那么當(dāng)他遞歸完時(shí),可能就生成typename P1, typename P2, typename P3, 結(jié)果
多了個(gè)逗號(hào),也許最后一次結(jié)果不該有逗號(hào)。

    ARG宏和PARAM宏本質(zhì)上相同,只是重復(fù)的符號(hào)不是typename Pn,而是Pn。

    最直接想到的是:

 

#define PARAM_1( n ) typename P##n
#define PARAM_2( n ) CHR( PARAM_, DEC( n ) )( DEC( n ) )##,typename P##n
#define PARAM_3( n ) CHR( PARAM_, DEC( n ) )( DEC( n ) )##,typename P##n 

 

    結(jié)果我們得到了個(gè)錯(cuò)誤的展開(kāi)結(jié)果:
typename PDEC( 2 ),typename PDEC( 3 ),typename P3

    這個(gè)問(wèn)題出在:PARAM_3( 3 )當(dāng)替換為 PARAM_2( DEC( n ) )時(shí),因?yàn)镻ARAM_2(n)宏對(duì)于宏參數(shù)n使用了##,也就是那個(gè)
typename P##n,所以這里不會(huì)把 DEC( n )展開(kāi),而是直接接到P后面。所以就成了typename PDEC( 3 )。

    為了消除這個(gè)問(wèn)題,我們改進(jìn)PARAM為:

 

#define TYPE( n ) ,typename P##n
#define PARAM_1( n ) CHR( typename P, n )
#define PARAM_2( n ) CHR( CHR( PARAM_, DEC( n ) )( DEC( n ) ), TYPE( n ) )
#define PARAM_3( n ) CHR( CHR( PARAM_, DEC( n ) )( DEC( n ) ), TYPE( n ) ) 

 

    之所以加入TYPE(n),是因?yàn)?,typename P##n 這個(gè)宏本身存在逗號(hào),將其直接用于宏體會(huì)出現(xiàn)問(wèn)題。

    于是,我們得到了正確的結(jié)果。

    其實(shí),PARAM系列宏宏體基本是一樣的,除了終止條件那個(gè)宏,為什么我們要寫(xiě)這么多呢?理由在于宏體不能自己調(diào)用
自己,所以才有了PARAM_3, PARAM_2。

    我們可以將上面的一系列宏抽象化,使其具有可復(fù)用性:

 

#define PARAM( n ) ,typename P##n
#define PARAM_END typename P 

#define ARG( n ) ,P##n
#define ARG_END P 

#define PARAM_1( n ) CHR( typename P, n )
#define PARAM_2( n ) CHR( CHR( PARAM_, DEC( n ) )( DEC( n ) ), TYPE( n ) )
#define PARAM_3( n ) CHR( CHR( PARAM_, DEC( n ) )( DEC( n ) ), TYPE( n ) ) 

#define REPEAT_1( n, f, e ) CHR( e, n )
#define REPEAT_2( n, f, e ) CHR( CHR( REPEAT_, DEC( n ) )( DEC( n ), f, e ), f( n ) )
#define REPEAT_3( n, f, e ) CHR( CHR( REPEAT_, DEC( n ) )( DEC( n ), f, e ), f( n ) ) 

#define DEF_PARAM( n ) REPEAT_##n( n, PARAM, PARAM_END )
#define DEF_ARG( n ) REPEAT_##n( n, ARG, ARG_END ) 

 

    我們創(chuàng)建了可重用的REPEAT系列宏,用于創(chuàng)建諸如typename P1, typename P2, typename P3或者P1,P2,P3之類的符號(hào),
通過(guò)更上層的DEF_PARAM(n)和DEF_ARG(n),就可以直接創(chuàng)建出我們上面所需要的符號(hào)串,例如:

    DEF_PARAM( 3 ) 就得到 typename P1, typename P2, typename P3
    DEF_ARG( 3 ) 就得到 P1, P2, P3

More in practice

    下載中提供了我使用這個(gè)宏遞歸技術(shù)寫(xiě)的lua_binder(如果你看過(guò)<實(shí)現(xiàn)自己的LUA綁定器-一個(gè)模板編程挑戰(zhàn) >),你
可以與上一個(gè)版本做一下比較,代碼少了很多。
    同樣,我希望你也能獲取這種宏遞歸的思想。   

相關(guān)下載

   使用宏遞歸的lua_binder

posted on 2008-08-20 17:48 Kevin Lynx 閱讀(12461) 評(píng)論(25)  編輯 收藏 引用 所屬分類: c/c++通用編程

評(píng)論

# re: 代碼自動(dòng)生成-宏遞歸思想[未登錄](méi) 2008-08-20 21:39 創(chuàng)

奇技淫巧還是慎用吧,代碼是寫(xiě)給人看的,而不是寫(xiě)給機(jī)器看的.  回復(fù)  更多評(píng)論   

# re: 代碼自動(dòng)生成-宏遞歸思想 2008-08-20 22:15 沈臻豪(foxtail)

用的好還是很好的,再說(shuō)賣弄賣弄也挺好。呵呵@創(chuàng)
  回復(fù)  更多評(píng)論   

# re: 代碼自動(dòng)生成-宏遞歸思想[未登錄](méi) 2008-08-20 23:07 創(chuàng)

@沈臻豪(foxtail)
你賣弄完了,接手或者閱讀你代碼的人會(huì)吐的.
  回復(fù)  更多評(píng)論   

# re: 代碼自動(dòng)生成-宏遞歸思想 2008-08-20 23:24 cexer

有的時(shí)候宏的確實(shí)很有用,BOOST里面有一個(gè)預(yù)處理元編程庫(kù)。  回復(fù)  更多評(píng)論   

# re: 代碼自動(dòng)生成-宏遞歸思想 2008-08-20 23:27 cexer

preprocessor,預(yù)處理元編程工具,包含重復(fù)和遞歸, 作者 Vesa Karvonen 和 Paul Mensonides.  回復(fù)  更多評(píng)論   

# re: 代碼自動(dòng)生成-宏遞歸思想 2008-08-20 23:58 x-matrix

@創(chuàng)
各種技術(shù)都有一定的應(yīng)用場(chǎng)合的,復(fù)雜的技術(shù)也是。  回復(fù)  更多評(píng)論   

# re: 代碼自動(dòng)生成-宏遞歸思想 2008-08-21 10:38 陳梓瀚(vczh)

仍然沒(méi)有解決問(wèn)題。真正的遞歸應(yīng)當(dāng)使得你那個(gè)PARAM(n)的n不受限制。不過(guò)這也沒(méi)辦法,是語(yǔ)法本身的限制。  回復(fù)  更多評(píng)論   

# re: 代碼自動(dòng)生成-宏遞歸思想 2008-08-22 11:17 空明流轉(zhuǎn)

很多任務(wù)我現(xiàn)在都用Code Generator做了。
用宏太多其實(shí)并不好。
不過(guò)Code Generator一般需要添加一些預(yù)編譯事件什么的  回復(fù)  更多評(píng)論   

# re: 代碼自動(dòng)生成-宏遞歸思想 2008-08-24 15:55 戴爾1420

通過(guò)宏遞歸有規(guī)律地產(chǎn)生一些符號(hào),來(lái)讓我們少寫(xiě)很多重復(fù)代碼,的確很新穎。  回復(fù)  更多評(píng)論   

# re: 代碼自動(dòng)生成-宏遞歸思想 2008-09-12 20:27 littlewater

很好,稍微改改可以支持更多的東西=3=
另外有一點(diǎn)可惜,MACRO好像不能夠處理另外一個(gè)MACRO(n)的連續(xù)迭代,因?yàn)榱硗庖粋€(gè)MACRO展開(kāi)以后可能會(huì)干擾正常的分析比如一個(gè)函數(shù)……  回復(fù)  更多評(píng)論   

# re: 代碼自動(dòng)生成-宏遞歸思想 2008-09-14 13:12 littlewater

再改進(jìn)了一下,如果是2005以上就可以任意了因?yàn)榭梢杂?..的MACRO處理……但是高興了半天以后才發(fā)現(xiàn)自家用的2003沒(méi)機(jī)會(huì)碰...立馬狂吐錯(cuò)誤……偶也吐了。。。。

ToT如果有很好的解決方案請(qǐng)告訴偶,謝謝了ToT,實(shí)在想不出來(lái)了

例子,比如第一輪使用了LZ的宏以后就會(huì)出現(xiàn)
template <typename R, DEF_PARAM( 1 )>
class functor<R( DEF_ARG( 1 ) )>;
template <typename R, DEF_PARAM( 2 )>
class functor<R( DEF_ARG( 2 ) )>;
template <typename R, DEF_PARAM( 3 )>
class functor<R( DEF_ARG( 3 ) )>;
顯然可以繼續(xù)用迭代的,但是問(wèn)題在于這些里面有,這個(gè)符號(hào)= =!!
有解決辦法么??  回復(fù)  更多評(píng)論   

# re: 代碼自動(dòng)生成-宏遞歸思想 2008-09-16 16:10 Kevin Lynx

#define PARAM( n ) ,typename P##n
#define PARAM_END typename P1

去掉那個(gè)逗號(hào)不就可以了?

有些不明白littlewater意思。  回復(fù)  更多評(píng)論   

# re: 代碼自動(dòng)生成-宏遞歸思想 2008-09-16 17:54 littlewater

不是這個(gè)意思,因?yàn)榈谝淮卧谑褂眠^(guò)宏遞歸以后:
template <typename R, DEF_PARAM( 1 )>
class functor<R( DEF_ARG( 1 ) )>;
會(huì)被展開(kāi)為理想的代碼:
template <typename R, typename P1>
class functor<R(P1)>;
問(wèn)題是這一輪繼續(xù)被遞歸的話:

DEF_XXX( template <typename R, typename P1> class functor<R(P1)>; )
實(shí)際上多了一個(gè)typename R的逗號(hào),應(yīng)該會(huì)被誤判的,結(jié)果參數(shù)變多了,明白了吧?  回復(fù)  更多評(píng)論   

# re: 代碼自動(dòng)生成-宏遞歸思想 2008-09-16 17:55 littlewater

怎么去掉那個(gè)逗號(hào)呢??  回復(fù)  更多評(píng)論   

# re: 代碼自動(dòng)生成-宏遞歸思想 2008-09-17 09:52 Kevin Lynx

@littlewater
依然不明白什么是“這一輪繼續(xù)被遞歸”,更不明白你寫(xiě)下的
“DEF_XXX( template <typename R, typename P1> class functor<R(P1)>; )

是為了說(shuō)明什么。

我推測(cè),你的意思是說(shuō),當(dāng)宏參數(shù)本身也是一個(gè)宏,而這個(gè)宏的宏體內(nèi)有逗號(hào)時(shí),將會(huì)出現(xiàn)歧義:
#define PARAM typename P1,
#define DEF_PARAM( a, b ) something

DEF_PARAM( PARAM, something ); 時(shí),在展開(kāi)宏體時(shí)就會(huì)出現(xiàn)DEF_PARAM( typename P1, , something ) 就會(huì)出現(xiàn)兩個(gè)逗號(hào)。

解決這個(gè)問(wèn)題的辦法時(shí),不讓PARAM宏提前展開(kāi)。

宏展開(kāi)的一個(gè)規(guī)則是:如果某個(gè)宏(如DEF_PARAM)的宏實(shí)參也是一個(gè)宏(如PARAM),那么在展開(kāi)這個(gè)宏之前,會(huì)先展開(kāi)宏實(shí)參,并將展開(kāi)后的宏體替換到宏中,然后第二次掃描,如果還有宏,則繼續(xù)展開(kāi)。

所以,解決辦法就是,讓實(shí)參不是一個(gè)宏!

宏展開(kāi)還有一個(gè)規(guī)則是:即使宏實(shí)參是一個(gè)宏,但是這個(gè)宏具有括號(hào)屬性,例如
#define PARAM( n ) ,typename P##n 中PARAM宏就是這么一個(gè)具有括號(hào)屬性的宏,該宏作為宏實(shí)參時(shí),如果沒(méi)有提供其參數(shù),那么它將被作為普通符號(hào),而不是一個(gè)宏。

因此,在代碼kl_macro_params.h中:
#define PARAM( n ) ,typename P##n
#define DEF_PARAM( n ) REPEAT_##n( n, PARAM, PARAM_END )

若DEF_PARAM( 2 ) 時(shí),會(huì)得到REPEAT_2( 2, PARAM, PARAM_END )展開(kāi)REPEAT_2宏時(shí),并不會(huì)先展開(kāi)PARAM,因?yàn)镻ARAM是一個(gè)具有括號(hào)屬性的宏,如果展開(kāi),那么將出現(xiàn)你說(shuō)的問(wèn)題。
  回復(fù)  更多評(píng)論   

# re: 代碼自動(dòng)生成-宏遞歸思想 2008-09-17 15:55 littlewater

不知道是不是 有點(diǎn)搞糊涂說(shuō)~
偶的意思是,首先受用KL的方法實(shí)現(xiàn):
template <typename R, DEF_PARAM( 1 )>
class functor<R( DEF_ARG( 1 ) )>;
template <typename R, DEF_PARAM( 2 )>
class functor<R( DEF_ARG( 2 ) )>;
template <typename R, DEF_PARAM( 3 )>
class functor<R( DEF_ARG( 3 ) )>;
就是說(shuō),我已經(jīng)通過(guò) KL系列宏遞歸 定義得到了三組functor的特化;
我現(xiàn)在呢,希望能夠繼續(xù)使用 KL系列宏遞歸,把這三個(gè)變化得到
#define TINST(n) \
template <typename R, DEF_PARAM( n )> \
class functor<R( DEF_ARG( n ) )>
接著得到:
TINST(1); TINST(2); TINST(3); ...
想能不能再用一次宏遞歸(就是所謂的再一次,連續(xù)遞歸的意思~)
#define DEF_TINST(n) REPEAT_##n( n, TINST1, TINST_END )
當(dāng)然TINST1和END分別是TINST(1)和TINST(n)了

然后只需要調(diào)用一次DEF_TINST(3);就完成了所有的任務(wù)了,增加或者減少一個(gè)定義只需要修改3為其他的數(shù)值,不需要再增加其他的代碼了

以上偶滴愿望,不知道是否說(shuō)得明白?

然后實(shí)際上似乎有問(wèn)題,8過(guò)不排除敝人的異常=v=+  回復(fù)  更多評(píng)論   

# re: 代碼自動(dòng)生成-宏遞歸思想 2008-09-17 17:35 littlewater

仔細(xì)再看了一遍KL的文章開(kāi)頭和KL最后的那個(gè)回復(fù),總算明白問(wèn)題所在=3=
實(shí)際上歸納了一下問(wèn)題是宏自身調(diào)用:
#define D(f,n) f(n)
#define A(n) B(n), D(B,n+1)
#define B(x) 1
int main( void )
{
int x[] = { D(A, n) };
return 0;
}
原來(lái)宏不能夠解開(kāi)自身,由于REPEAT_xx偶在連續(xù)遞歸的時(shí)候重復(fù)調(diào)用了自身OTL,因?yàn)楸容^龐大失誤了,而且對(duì)宏不熟悉——
現(xiàn)在好了,也不需要考慮是2005了——感謝。。。
  回復(fù)  更多評(píng)論   

# re: 代碼自動(dòng)生成-宏遞歸思想[未登錄](méi) 2008-09-24 11:01 Kevin Lynx

今天發(fā)現(xiàn)boost果然有這么一個(gè)宏庫(kù):
http://www.boost.org/doc/libs/1_36_0/libs/preprocessor/doc/index.html

然后在<C++ Template Metaprogramming>一書(shū)里也看到類似的闡述:
http://www.boostpro.com/tmpbook/preprocessor.html

原來(lái)我又重造了一次輪子,還沒(méi)造好。 = =|
  回復(fù)  更多評(píng)論   

# re: 代碼自動(dòng)生成-宏遞歸思想 2008-09-24 15:53 littlewater

不,很不錯(cuò)了,現(xiàn)在也可以比較一下,看看差距=3=~  回復(fù)  更多評(píng)論   

# re: 代碼自動(dòng)生成-宏遞歸思想 2009-11-23 09:43 Scan

我感覺(jué)你那個(gè)根本不是遞歸啊
既然宏的部分也得編碼, 那為何不這樣?

#define PARAM_1(t) t T
#define PARAM_2(t) PARAM_1(t), t T2
#define PARAM_3(t) PARAM_2(t), t T3

#define PARAM(n, t) PARAM_##n(t)

#define TO_STRING1(x) #x
#define TO_STRING(x) TO_STRING1(x)

int main()
{
cout << TO_STRING(PARAM(3, typename)) << endl;
cout << TO_STRING(PARAM(3, )) << endl;
}  回復(fù)  更多評(píng)論   

# re: 代碼自動(dòng)生成-宏遞歸思想 2011-01-13 00:03 溪流

有沒(méi)有辦法只出現(xiàn)一次 DEX_XX 這樣的系列宏,
之后不要出現(xiàn) PARAM_1 PARAM_2 PARAM_3 呢?  回復(fù)  更多評(píng)論   

# re: 代碼自動(dòng)生成-宏遞歸思想 2011-01-13 09:10 Kevin Lynx

@溪流
從原理上來(lái)看的話,我們最終需要的是各種帶有1、2、3之類的相似符號(hào),例如 typename P1,typename P2,....,所以,逐步拆分這些符號(hào)后,就會(huì)自然而然地得到”基礎(chǔ)數(shù)字序列生成器”:DEC。

相當(dāng)于,DEC系列宏就是這個(gè)宏庫(kù)的基礎(chǔ),而PARAM_1則算是稍微上層一點(diǎn)的應(yīng)用。

ps,很久沒(méi)搗鼓這些復(fù)雜的東西,諸多遺忘,見(jiàn)諒。  回復(fù)  更多評(píng)論   

# re: 代碼自動(dòng)生成-宏遞歸思想 2011-07-07 23:19 enjoylife

考慮要用宏計(jì)算一組100至1000的階層,不能寫(xiě)901行FAC_3( n )的調(diào)用吧。寫(xiě)成for(int i=100;i<=1000;i++) FAC_3(i)又不行。怎么辦?  回復(fù)  更多評(píng)論   

# re: 代碼自動(dòng)生成-宏遞歸思想 2011-07-07 23:31 enjoylife

這組計(jì)算階層的宏,只能計(jì)算到3的階層...考慮有什么辦法可以往上加?  回復(fù)  更多評(píng)論   

# re: 代碼自動(dòng)生成-宏遞歸思想 2015-05-08 20:04 邊城浪

有意思. 非常棒  回復(fù)  更多評(píng)論   

青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品
  • <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>
            亚洲综合第一| 先锋a资源在线看亚洲| 亚洲国产精品成人综合| 99精品视频网| 欧美国产精品专区| 亚洲成人直播| 久久久久在线观看| 亚洲中午字幕| 国产精品欧美一区喷水| 亚洲一区二区黄色| 一区二区免费在线观看| 欧美日韩国产成人在线91| 亚洲人永久免费| 亚洲大胆人体在线| 免费亚洲电影在线观看| 136国产福利精品导航网址| 久久综合色播五月| 久久久久久久久久久成人| 国产精品网红福利| 欧美在线观看网站| 欧美在线免费观看亚洲| 国产欧美一区二区三区国产幕精品| 宅男精品视频| 亚洲视频免费看| 国产精品入口日韩视频大尺度| 亚洲视频成人| 亚洲一区不卡| 亚洲韩日在线| 午夜精品成人在线| 中文国产一区| 国产欧美一区二区视频| 久久精品国产久精国产爱| 欧美一区二区三区在线观看| 黄色亚洲大片免费在线观看| 欧美激情精品久久久| 欧美精品一区二区三区蜜桃| 在线综合+亚洲+欧美中文字幕| 亚洲深夜av| 精品88久久久久88久久久| 欧美国产日韩精品| 欧美日韩国产综合视频在线观看 | 欧美激情精品久久久久久蜜臀| 亚洲精品一区二区三区四区高清| 亚洲精品一区二区三区不| 欧美三级午夜理伦三级中文幕| 午夜精品一区二区在线观看| 欧美中文在线视频| 亚洲国产综合在线| 一区二区三区偷拍| 狠狠狠色丁香婷婷综合久久五月| 亚洲第一中文字幕在线观看| 欧美三级在线| 免费成人高清在线视频| 欧美日韩成人免费| 久久久91精品| 欧美精品九九| 久久久精品视频成人| 欧美肥婆在线| 久久久久国产精品厨房| 欧美精品麻豆| 久久深夜福利免费观看| 欧美日韩在线播放三区| 另类av一区二区| 国产精品视频| 亚洲精品国产精品国自产观看浪潮 | 性久久久久久久久久久久| 久久婷婷一区| 欧美亚洲一级片| 免费亚洲一区二区| 欧美在线一二三区| 欧美日韩在线三级| 欧美国产成人在线| 国产综合色在线视频区| 在线亚洲电影| 99精品视频一区二区三区| 久久国产精品99国产| 一区二区三区免费在线观看| 久久免费国产| 久久久久综合一区二区三区| 国产精品国产三级国产专播品爱网| 欧美激情视频免费观看| 韩日视频一区| 午夜在线视频观看日韩17c| 亚洲午夜成aⅴ人片| 欧美sm重口味系列视频在线观看| 亚洲欧美日韩网| 妖精成人www高清在线观看| 久久久综合免费视频| 国产精品乱人伦一区二区| 亚洲国内在线| 亚洲国产欧美一区二区三区久久 | 国产精品免费网站| 一本大道久久a久久精品综合 | 中文欧美在线视频| 一区二区不卡在线视频 午夜欧美不卡在 | 久久综合999| 久久久久久国产精品mv| 国产农村妇女精品一二区| 亚洲午夜电影网| 亚洲欧美国产77777| 欧美三级小说| 亚洲一二三级电影| 香蕉精品999视频一区二区 | 欧美天天综合网| 一本色道久久综合精品竹菊 | 欧美涩涩视频| 正在播放亚洲一区| 亚洲综合视频网| 国产精品久久毛片a| 亚洲一区二区三区精品视频| 性色av香蕉一区二区| 国产日韩精品视频一区| 久久精品国产77777蜜臀| 久久综合久色欧美综合狠狠| 在线观看欧美日韩国产| 久久日韩粉嫩一区二区三区| 久久男女视频| 国产精品高潮呻吟久久| 亚洲综合社区| 久久久久久夜| 亚洲三级国产| 欧美日韩在线观看视频| 亚洲欧美日韩久久精品| 免费不卡中文字幕视频| 亚洲国产婷婷香蕉久久久久久| 欧美精品一区二区三| 亚洲视频导航| 六月婷婷一区| 一个色综合导航| 久久国产手机看片| 亚洲欧洲在线免费| 亚洲欧洲av一区二区| 激情视频亚洲| 欧美顶级少妇做爰| 亚洲天堂男人| 一区二区亚洲精品| 欧美日本在线播放| 欧美在线91| 亚洲免费电影在线| 久久阴道视频| 亚洲综合日本| 亚洲黄色有码视频| 国产精品男女猛烈高潮激情| 久久一区激情| 亚洲综合日韩在线| 亚洲国产成人在线视频| 久久激情综合网| 在线亚洲成人| 欧美日韩一区二区精品| 久久视频在线视频| 亚洲欧美日韩电影| 亚洲美女一区| 欧美 日韩 国产 一区| 欧美一级一区| 一区二区三区**美女毛片| 精品91免费| 国产亚洲午夜| 国产精品成人免费| 欧美精品v国产精品v日韩精品| 久久精品首页| 久久超碰97人人做人人爱| 亚洲一区二区在线免费观看| 亚洲另类春色国产| 亚洲第一精品在线| 欧美福利在线| 欧美+亚洲+精品+三区| 久久久亚洲影院你懂的| 欧美中文字幕视频| 欧美一区二区福利在线| 亚洲欧美成人| 性做久久久久久免费观看欧美| 亚洲视频欧洲视频| 亚洲视频精选| 亚洲综合首页| 亚洲免费中文| 欧美亚洲综合久久| 欧美在线观看网站| 久久精品夜夜夜夜久久| 久久久久久国产精品一区| 久久精品免视看| 久久欧美肥婆一二区| 久久综合网络一区二区| 免费在线欧美视频| 蜜桃精品久久久久久久免费影院| 久久女同互慰一区二区三区| 久久精品一级爱片| 久久久久看片| 免费不卡在线观看av| 美日韩精品视频免费看| 欧美.日韩.国产.一区.二区| 免播放器亚洲一区| 亚洲高清资源综合久久精品| 亚洲动漫精品| 在线播放不卡| 亚洲日本一区二区三区| 亚洲国产精品电影| 在线日韩成人| 9久草视频在线视频精品| 亚洲美女视频| 9l视频自拍蝌蚪9l视频成人|