【為宏正名】99%人都不知道的"##"里用法
掃描二維碼
隨時(shí)隨地手機(jī)看文章
【說在前面的話】
【"##"的“表”用法】
實(shí)際中,我們可以這樣使用:
def_u32_array(sample_buffer, 64)
宏展開的效果是:
uint32_t array_sample_buffer[64];
可以看到,"array__"與形參“__name”是沒有天然分割的,因此要想將"array_"與"__name"所代表的內(nèi)容(而不是__name本身)粘連在一起,就需要“##”運(yùn)算的幫助。另一方面,"__name"與"["是具有天然分隔的——編譯器不會(huì)認(rèn)為"__name"與"["是連接在一起的,因此這里并不需要畫蛇添足的使用"##"運(yùn)算——如果你這么做了,預(yù)編譯器會(huì)毫不猶豫的告訴你語法錯(cuò)誤。——這是"##"運(yùn)算的普通用法,在過去轉(zhuǎn)載的文章《C語言#和##連接符在項(xiàng)目中的應(yīng)用(漂亮)》中也有詳細(xì)介紹,這里就不再贅述。
【"##"的官方“里”用法】
{ \
uint32_t int_flag = __disable_irq(); \
__VA_ARGS__ \
__set_PRIMASK(int_flag); \
}
這里定義了一個(gè)宏"safe_atom_code()",在括號(hào)內(nèi),無論你填寫任何內(nèi)容,都會(huì)被無條件的放置到“__VA_ARGS__”所在的位置,你可以認(rèn)為括號(hào)里的“...”實(shí)際上就是對(duì)應(yīng)"__VA_ARGS__"。比如,我們可以寫下這樣的代碼:
/**
\fn void wr_dat (uint16_t dat)
\brief Write data to the LCD controller
\param[in] dat Data to write
*/
static __inline void wr_dat (uint_fast16_t dat)
{
safe_atom_code(
LCD_CS(0);
GLCD_PORT->DAT = (dat >> 8); /* Write D8..D15 */
GLCD_PORT->DAT = (dat & 0xFF); /* Write D0..D7 */
LCD_CS(1);
)
}
這個(gè)代碼確保在向寄存器GCLD_PORT->DAT寫入數(shù)據(jù)時(shí)不會(huì)被其它中斷打斷。
{ \
uint32_t int_flag = __disable_irq(); \
__CODE \
__set_PRIMASK(int_flag); \
}
你不僅提出了問題,甚至還實(shí)際測(cè)試了下,似乎完全等效,“根本沒差別嘛!”——你驚呼道。然而,事實(shí)上并沒有那么簡(jiǎn)單:
參數(shù)宏是通過“,”來作為分隔符來計(jì)算用戶實(shí)際產(chǎn)傳入了幾個(gè)參數(shù)的,或者換句話說,在使用參數(shù)宏的時(shí)候,預(yù)編譯器是看不懂C語法的——在它眼中,除了它所認(rèn)識(shí)的少數(shù)符號(hào)外,其它東西都是無意義的字符串——由于在處理括號(hào)內(nèi)部的內(nèi)容時(shí),它只認(rèn)識(shí)","和"...",因此當(dāng)括號(hào)中的內(nèi)容每增加一個(gè)",",與編譯器就認(rèn)為多了一個(gè)參數(shù)。
當(dāng)你使用參數(shù)宏的時(shí)候,傳入?yún)?shù)的個(gè)數(shù)(已“,”分開)必須與定義參數(shù)宏時(shí)候形參的數(shù)量完全一致;當(dāng)不一致的時(shí)候,預(yù)編譯器可能不會(huì)報(bào)錯(cuò),而是直接無視了你的參數(shù)宏——把它傳遞到編譯的下一階段,因而往往會(huì)被認(rèn)作是一個(gè)函數(shù)——事實(shí)上這個(gè)函數(shù)是不存在的,因此在鏈接階段會(huì)報(bào)告某某函數(shù)未定義的錯(cuò)誤。這時(shí)候你就會(huì)納悶了,為啥我明明定義的是一個(gè)宏,編譯器卻把它當(dāng)作函數(shù)呢?
可變參數(shù)宏的引入就解決了這個(gè)問題:
"..."只能放在參數(shù)宏形參列表的最后;
當(dāng)用戶的參數(shù)個(gè)數(shù)超過了規(guī)定的參數(shù)個(gè)數(shù)時(shí),所有多出來的內(nèi)容會(huì)一股腦的由“__VA_ARGS__”所背負(fù);
當(dāng)用戶的參數(shù)個(gè)數(shù)正好等于形參的個(gè)數(shù)時(shí),"__VA_ARGS__"就等效于一個(gè)空字符串
回頭再來看前面的問題,
與
的差別在于,前者括號(hào)里可以放包括","在內(nèi)的幾乎任意內(nèi)容;而后者則完全不能容忍逗號(hào)的存在——比如你調(diào)用了一個(gè)函數(shù),函數(shù)的參數(shù)要用到都好隔開吧?再比如,你用到了逗號(hào)表達(dá)式……——想想都很酸爽。
因此,使用的時(shí)候,我們可以這樣寫:
log_info("------------------------------------\r\n");
log_info(" Cycle Count : %d", total_cycle_cnt);
宏展開后實(shí)際上對(duì)應(yīng)于:
printf("------------------------------------\r\n",);
printf(" Cycle Count : %d", total_cycle_cnt);
看似沒有問題,注意到一個(gè)細(xì)節(jié)沒有?在第一個(gè)printf()的最后多了一個(gè)","。雖然有些編譯器,例如GCC并不會(huì)計(jì)較(也許就是一個(gè)warning),但對(duì)于廣大潔癖嚴(yán)重的處女座程序員來說,這怎么能忍,于是在ANSI-C99標(biāo)準(zhǔn)引入可變參數(shù)宏的時(shí)候,又貼心了加了一個(gè)不那么起眼的語法:當(dāng)下面的組合出現(xiàn)時(shí) ",##__VA_ARGS__",如果__VA_ARGS__是一個(gè)空字符串,則前面的","會(huì)一并被刪除掉。因此,上面的宏可以改寫為:
printf(__STRING,##__VA_ARGS__) define log_info(__STRING, ...)
此時(shí),前面的代碼會(huì)被展開為:
printf("------------------------------------\r\n");
printf(" Cycle Count : %d", total_cycle_cnt);
處女座表示,這次可以安心睡覺了。
【正文:"##"的騷操作】
當(dāng)我們使用參數(shù)宏的時(shí)候在括號(hào)里不填寫任何內(nèi)容,最終會(huì)展開為僅有默認(rèn)值的情況:
EXAMPLE();
被展開為:
( 默認(rèn)值 )
當(dāng)我們提供了任意的有效值時(shí),則會(huì)被展開成逗號(hào)表達(dá)式:
EXAMPLE(我們提供的值);
被展開為:
( 默認(rèn)值, 我們提供的值 )
這個(gè)技巧其實(shí)對(duì)API的封裝特別有效:它允許我們簡(jiǎn)化函數(shù)API的使用,比如在用戶忽略的情況下,自動(dòng)給函數(shù)填充某些默認(rèn)值,而在用戶主動(dòng)提供參數(shù)的情況下,替代那些默認(rèn)值。這里我舉兩個(gè)現(xiàn)實(shí)中的例子:
-
為函數(shù)提供默認(rèn)的參數(shù)
假設(shè)我們有一個(gè)初始化函數(shù),初始化函數(shù)允許用戶通過結(jié)構(gòu)體來配置一些參數(shù):
typedef struct xxxx_cfg_t {
...
} xxxx_cfg_t;
int xxxx_init(xxxx_cfg_t *cfg_ptr);
為了簡(jiǎn)化用戶的配置過程,初始化函數(shù)會(huì)檢查指針cfg_ptr是否為NULL,如果為NULL則自動(dòng)使用默認(rèn)配置,反之將使用用戶定義的配置。此時(shí),我們可以通過宏來提供默認(rèn)值NULL:
為消息處理提供默認(rèn)的掩碼配置
有些消息處理函數(shù)可以批量的處理某一類消息,而具體選中了哪些消息類別,則通常由二進(jìn)制掩碼來表示,例如:
typedef struct msg_t msg_t;
struct {
uint16_t msg;
uint16_t mask;
int (*handler)(msg_t *msg_ptr);
} msg_t;
const msg_t __name[] = {__VA_ARGS__};
{ \
.msg = (__msg), \
.handler = &(__handler), \
.msk = (0xFFFF,
}
/*! \note 高字節(jié)表示操作的類別:
比如0x00表示控制類,0x01表示W(wǎng)RITE,0x02表示READ
*/
enum {
SIGN_UP = 0x0001,
WRITE_MEM = 0x0100,
WRITE_SRAM = 0x0101,
WRITE_FLASH = 0x0102,
WRITE_EEPROM = 0x0103,
READ_MEM = 0x0200,
READ_SRAM = 0x0201,
READ_FLASH = 0x0202,
READ_EEPROM = 0x0203,
};
extern int iap_sign_up_handler(msg_t *msg_ptr);
extern int iap_write_mem(msg_t *msg_ptr);
extern int iap_read_mem(msg_t *msg_ptr);
def_msg_map( iap_message_map
/* 嚴(yán)格的將 SIGN_UP 映射到 對(duì)應(yīng)的處理函數(shù)中 */
add_msg( SIGN_UP, iap_sign_up_handler ),
/* 批量處理所有的WRITE操作,使用掩碼進(jìn)行過濾*/
add_msg( WRITE_MEM, iap_write_mem, 0xFF00 ),
/* 批量處理所有的READ操作,使用掩碼進(jìn)行過濾 */
add_msg( READ_MEM, iap_read_mem, 0xFF00 ),
)
【結(jié)語】
免責(zé)聲明:本文內(nèi)容由21ic獲得授權(quán)后發(fā)布,版權(quán)歸原作者所有,本平臺(tái)僅提供信息存儲(chǔ)服務(wù)。文章僅代表作者個(gè)人觀點(diǎn),不代表本平臺(tái)立場(chǎng),如有問題,請(qǐng)聯(lián)系我們,謝謝!