UNREFERENCED_PARAMETER的用處
作用：告訴編譯器，已經使用了該變量，不必檢測警告！
在VC編譯器下，如果您用***别進行編譯，編譯器就會很苛刻地指出您的非常細小的警告。當你生命了一個變量，而沒有使用時，編譯器就會報警告：
“warning C4100: ''ＸＸＸＸ'' : unreferenced formal parameter.”
是以，為了讓編譯器不必檢測你的警告，就使用UNREFERENCED_PARAMETER語句。比如：
int SomeFunction(int arg1, int arg2)
{
UNREFERENCED_PARAMETER(arg2)
...
}
我看到過一些 C++ 代碼針對沒有使用過的參數用 UNREFERENCED_PARAMETER，例如：
int SomeFunction(int arg1, int arg2)
{
UNREFERENCED_PARAMETER(arg2)
...
}
我還看到過這樣的代碼：
int SomeFunction(int arg1, int /* arg2 */)
{
...
}
你能解釋它們的差别嗎？哪一種用法更好？
Judy McGeough
是啊！為什麼呢？讓我們從 UNREFERENCED_PARAMETER 開始吧。這個宏在 winnt.h 中定義如下：
#define UNREFERENCED_PARAMETER(P) (P)
換句話說 UNREFERENCED_PARAMETER 展開傳遞的參數或表達式。其目的是避免編譯器關于未引用參數的警告。許多程式員，包括我在内，喜歡用***别的警告 Level 4（/W4）進行編譯。Level 4 屬于“能被安全忽略的事件”的範疇。雖然它們可能使你難堪，但很少破壞你的代碼。例如，在你的程式中可能會有這樣一些代碼行：
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 相同的訣竅，那就是注釋函數署名中的參數名：
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 選項我沒有在本文讨論。有關它們的資訊請參考相關文檔。
![win32之Hello World[圖]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)