UNREFERENCED_PARAMETER 的做用
2007年06月16日 星期六 14:38
咱們從 UNREFERENCED_PARAMETER 開始吧。這個宏在 winnt.h 中定義以下:
#define UNREFERENCED_PARAMETER(P) (P)
換句話說 UNREFERENCED_PARAMETER 展開傳遞的參數或表達式。其目的是避免編譯器關於未引用參數的警告。許多程序員,包括我在內,喜歡用最高級別的警告 Level 4(/W4)進行編譯。Level 4 屬於「能被安全忽略的事件」的範疇。雖然它們可能使你難堪,但不多破壞你的代碼。例如,在你的程序中可能會有這樣一些代碼行:java
int x=1;
但你從沒用到過 x。也許這一行是你之前使用 x 時留下來的,只刪除了使用它的代碼,而忘了刪除這個變量。Warning Level 4 能找到這些小麻煩。因此,爲何不讓編譯器幫助你完成多是最高級別的專業化呢?用Level 4 編譯是展現你工做態度的一種方式。若是你爲公衆使用者編寫庫,Level 4 則是社交禮節上須要的。你不想強迫你的開發人員使用低級選項清潔地編譯他們的代碼。
問題是,Level 4 實在是太過於注意細節,在 Level 4 上,編譯器連未引用參數這樣無傷大雅的事情也要抱怨(固然,除非你真的有意使用這個參數,這時便相安無事)。假設你有一個函數帶來兩個參數,但你只使用其中一個:程序員
int SomeFunction(int arg1, int arg2){ return arg1+5;}
使用 /W4,編譯器抱怨:安全
「warning C4100: ''arg2'' : unreferenced formal parameter.」
爲了騙過編譯器,你能夠加上 UNREFERENCED_PARAMETER(arg2)。如今編譯器在編譯你的引用 arg2 的函數時便會住口。而且因爲語句:函數
arg2;
實際上不作任何事情,編譯器不會爲之產生任何代碼,因此在空間和性能上不會有任何損失。性能
細心的人可能會問:既然你不使用 arg2,那當初爲什麼要聲明它呢?一般是由於你實現某個函數以知足某些API固有的署名須要,例如,MFC的 OnSize 處理例程的署名必需要像下面這樣:編碼
void OnSize(UINT nType, int cx, int cy);
這裏 cx/cy 是窗口新的寬/高,nType 是一個相似 SIZE_MAXIMIZED 或 SIZE_RESTORED 這樣的編碼,表示窗口是否最大化或是常規大小。通常你不會在乎 nType,只會關注 cx 和 xy。因此若是你想用 /W4,則必須使用 UNREFERENCED_PARAMETER(nType)。OnSize 只是上千個 MFC 和 Windows 函數之一。編寫一個基於 Windows 的程序,幾乎不可能不碰到未引用參數。
說了這麼多關於 UNREFERENCED_PARAMETER 內容。Judy 在她的問題中還提到了另外一個 C++ 程序員經常使用的而且其做用與 UNREFERENCED_PARAMETER 相同的訣竅,那就是註釋函數署名中的參數名:orm
void CMyWnd::OnSize(UINT /* nType */, int cx, int cy){}
如今 nType 是未命名參數,其效果就像你敲入 OnSize(UINT, int cx, int cy)同樣。那麼如今的關鍵問題是:你應該使用哪一種方法——未命名參數,仍是 UNREFERENCED_PARAMETER?
大多數狀況下,二者沒什麼區別,使用哪個純粹是風格問題。(你喜歡你的 java 咖啡是黑色仍是奶油的顏色?)但我認爲至少有一種狀況必須使用 UNREFERENCED_PARAMETER。假設你決定窗口不容許最大化。那麼你便禁用 Maximize 按鈕,從系統菜單中刪除,同時阻止每個用戶可以最大化窗口的操做。由於你是偏執狂(大多數好的程序員都是偏執狂),你添加一個 ASSERT (斷言)以確保代碼按照你的意圖運行:事件
void CMyWnd::OnSize(UINT nType, int cx, int cy){ ASSERT(nType != SIZE_MAXIMIZE); ... // use cx, cy}
質檢團隊竭盡所能以各類方式運行你的程序,ASSERT 從沒有彈出過,因而你認爲編譯生成 Release 版本是安全的。可是此時 _DEBUG 定義沒有了,ASSERT(nType != SIZE_MAXIMIZE)展開爲 ((void)0),而且 nType 一會兒成了一個未引用參數!這樣進入你乾淨的編譯。你沒法註釋掉參數表中的 nType,由於你要在 ASSERT 中使用它。因而在這種狀況下——你惟一使用參數的地方是在 ASSERT 中或其它 _DEBUG 條件代碼中——只有 UNREFERENCED_PARAMETER 會保持編譯器在 Debug 和 Release 生成模式下都沒有問題。知道了嗎?
結束討論以前,我想還有一個問題我沒有說起,就是你能夠象下面這樣用 pragma 指令抑制單一的編譯器警告:開發
#pragma warning( disable : 4100 )
4100 是未引用參數的出錯代碼。pragma 抑制其他文件/模塊的該警告。用下面方法能夠從新啓用這個警告:文檔
#pragma warning( default : 4100 )
無論怎樣,較好的方法是在禁用特定的警告以前保存全部的警告狀態,而後,等你作完以後再回到之前的配置。那樣,你便回到的之前的狀態,這個狀態不必定是編譯器的默認狀態。
因此你能象下面這樣在代碼的先後用 pragma 指令抑制單個函數的未引用參數警告:
#pragma warning( push ) #pragma warning( disable : 4100 )void SomeFunction(...){}#pragma warning( pop ) 固然,對於未引用參數而言,這種方法未免冗長,但對於其它類型的警告來講可能就不是這樣了。庫生成者都是用 #pragma warning 來阻塞警告,這樣他們的代碼能夠用 /W4 進行清潔編譯。MFC 中充滿了這樣的 pragmas 指令。還有好多的 #pragma warning 選項我沒有在本文討論。有關它們的信息請參考相關文檔。