作用：告訴編譯器，已經(jīng)使用了該變量，不必檢測(cè)警告！
在VC編譯器下，如果您用最高級(jí)別進(jìn)行編譯，編譯器就會(huì)很苛刻地指出您的非常細(xì)小的警告。當(dāng)你生命了一個(gè)變量，而沒有使用時(shí)，編譯器就會(huì)報(bào)警告：
“warning C4100: ''ＸＸＸＸ'' : unreferenced formal parameter.”
所以，為了讓編譯器不必檢測(cè)你的警告，就使用UNREFERENCED_PARAMETER語句。比如：
int SomeFunction(int arg1, int arg2)
{
UNREFERENCED_PARAMETER(arg2)
...
}
===============================================================================
[ 翻譯文檔 本文適合中級(jí)讀者 已閱讀9439次 ] 文檔 代碼 工具
C++ At Work 專欄...
未引用參數(shù)，添加任務(wù)欄命令及其它...
原著：Paul DiLascia
翻譯：NorthTibet
下載源代碼：CAtWork0505.exe (171KB)
原文出處：Unreferenced Parameters, Adding Task Bar Commands, and More
未引用參數(shù)
添加任務(wù)欄命令
我看到過一些 C++ 代碼針對(duì)沒有使用過的參數(shù)用 UNREFERENCED_PARAMETER，例如：
int SomeFunction(int arg1, int arg2)
{
UNREFERENCED_PARAMETER(arg2)
...
}
我還看到過這樣的代碼：
int SomeFunction(int arg1, int /* arg2 */)
{
...
}
你能解釋它們的差別嗎？哪一種用法更好？
Judy McGeough
是??！為什么呢？讓我們從 UNREFERENCED_PARAMETER 開始吧。這個(gè)宏在 winnt.h 中定義如下：
#define UNREFERENCED_PARAMETER(P) (P) 換句話說 UNREFERENCED_PARAMETER 展開傳遞的參數(shù)或表達(dá)式。其目的是避免編譯器關(guān)于未引用參數(shù)的警告。許多程序員，包括我在內(nèi)，喜歡用最高級(jí)別的警告 Level 4（/W4）進(jìn)行編譯。Level 4 屬于“能被安全忽略的事件”的范疇。雖然它們可能使你難堪，但很少破壞你的代碼。例如，在你的程序中可能會(huì)有這樣一些代碼行：
int x=1; 但你從沒用到過 x。也許這一行是你以前使用 x 時(shí)留下來的，只刪除了使用它的代碼，而忘了刪除這個(gè)變量。Warning Level 4 能找到這些小麻煩。所以，為什么不讓編譯器幫助你完成可能是最高級(jí)別的專業(yè)化呢？用Level 4 編譯是展示你工作態(tài)度的一種方式。如果你為公眾使用者編寫庫，Level 4 則是社交禮節(jié)上需要的。你不想強(qiáng)迫你的開發(fā)人員使用低級(jí)選項(xiàng)清潔地編譯他們的代碼。
問題是，Level 4 實(shí)在是太過于注意細(xì)節(jié)，在 Level 4 上，編譯器連未引用參數(shù)這樣無傷大雅的事情也要抱怨（當(dāng)然，除非你真的有意使用這個(gè)參數(shù)，這時(shí)便相安無事）。假設(shè)你有一個(gè)函數(shù)帶來兩個(gè)參數(shù)，但你只使用其中一個(gè)：
int SomeFunction(int arg1, int arg2)
{
return arg1+5;
}使用 /W4，編譯器抱怨：
“warning C4100: ''arg2'' : unreferenced formal parameter.”為了騙過編譯器，你可以加上 UNREFERENCED_PARAMETER(arg2)?，F(xiàn)在編譯器在編譯你的引用 arg2 的函數(shù)時(shí)便會(huì)住口。并且由于語句：
arg2;實(shí)際上不做任何事情，編譯器不會(huì)為之產(chǎn)生任何代碼，所以在空間和性能上不會(huì)有任何損失。
細(xì)心的人可能會(huì)問：既然你不使用 arg2，那當(dāng)初為何要聲明它呢？通常是因?yàn)槟銓?shí)現(xiàn)某個(gè)函數(shù)以滿足某些API固有的署名需要，例如，MFC的 OnSize 處理例程的署名必須要像下面這樣：
void OnSize(UINT nType, int cx, int cy); 這里 cx/cy 是窗口新的寬/高，nType 是一個(gè)類似 SIZE_MAXIMIZED 或 SIZE_RESTORED 這樣的編碼，表示窗口是否最大化或是常規(guī)大小。一般你不會(huì)在意 nType，只會(huì)關(guān)注 cx 和 xy。所以如果你想用 /W4，則必須使用 UNREFERENCED_PARAMETER(nType)。OnSize 只是上千個(gè) MFC 和 Windows 函數(shù)之一。編寫一個(gè)基于 Windows 的程序，幾乎不可能不碰到未引用參數(shù)。
說了這么多關(guān)于 UNREFERENCED_PARAMETER 內(nèi)容。Judy 在她的問題中還提到了另一個(gè) C++ 程序員常用的并且其作用與 UNREFERENCED_PARAMETER 相同的訣竅，那就是注釋函數(shù)署名中的參數(shù)名：
void CMyWnd::OnSize(UINT /* nType */,
int cx, int cy)
{
} 現(xiàn)在 nType 是未命名參數(shù)，其效果就像你敲入 OnSize(UINT, int cx, int cy)一樣。那么現(xiàn)在的關(guān)鍵問題是：你應(yīng)該使用哪種方法——未命名參數(shù)，還是 UNREFERENCED_PARAMETER？
大多數(shù)情況下，兩者沒什么區(qū)別，使用哪一個(gè)純粹是風(fēng)格問題。（你喜歡你的 java 咖啡是黑色還是奶油的顏色？）但我認(rèn)為至少有一種情況必須使用 UNREFERENCED_PARAMETER。假設(shè)你決定窗口不允許最大化。那么你便禁用 Maximize 按鈕，從系統(tǒng)菜單中刪除，同時(shí)阻止每一個(gè)用戶能夠最大化窗口的操作。因?yàn)槟闶瞧珗?zhí)狂（大多數(shù)好的程序員都是偏執(zhí)狂），你添加一個(gè) ASSERT （斷言）以確保代碼按照你的意圖運(yùn)行：
void CMyWnd::OnSize(UINT nType, int cx, int cy)
{
ASSERT(nType != SIZE_MAXIMIZE);
... // use cx, cy
} 質(zhì)檢團(tuán)隊(duì)竭盡所能以各種方式運(yùn)行你的程序，ASSERT 從沒有彈出過，于是你認(rèn)為編譯生成 Release 版本是安全的。但是此時(shí) _DEBUG 定義沒有了，ASSERT(nType != SIZE_MAXIMIZE)展開為 ((void)0)，并且 nType 一下子成了一個(gè)未引用參數(shù)！這樣進(jìn)入你干凈的編譯。你無法注釋掉參數(shù)表中的 nType，因?yàn)槟阋?ASSERT 中使用它。于是在這種情況下——你唯一使用參數(shù)的地方是在 ASSERT 中或其它 _DEBUG 條件代碼中——只有 UNREFERENCED_PARAMETER 會(huì)保持編譯器在 Debug 和 Release 生成模式下都沒有問題。知道了嗎？
結(jié)束討論之前，我想還有一個(gè)問題我沒有提及，就是你可以象下面這樣用 pragma 指令抑制單一的編譯器警告：
#pragma warning( disable : 4100 )4100 是未引用參數(shù)的出錯(cuò)代碼。pragma 抑制其余文件/模塊的該警告。用下面方法可以重新啟用這個(gè)警告：
#pragma warning( default : 4100 ) 不管怎樣，較好的方法是在禁用特定的警告之前保存所有的警告狀態(tài)，然后，等你做完之后再回到以前的配置。那樣，你便回到的以前的狀態(tài)，這個(gè)狀態(tài)不一定是編譯器的默認(rèn)狀態(tài)。
所以你能象下面這樣在代碼的前后用 pragma 指令抑制單個(gè)函數(shù)的未引用參數(shù)警告：
#pragma warning( push )
#pragma warning( disable : 4100 )
void SomeFunction(...)
{
}
#pragma warning( pop ) 當(dāng)然，對(duì)于未引用參數(shù)而言，這種方法未免冗長，但對(duì)于其它類型的警告來說可能就不是這樣了。庫生成者都是用 #pragma warning 來阻塞警告，這樣他們的代碼可以用 /W4 進(jìn)行清潔編譯。MFC 中充滿了這樣的 pragmas 指令。還有好多的 #pragma warning 選項(xiàng)我沒有在本文討論。有關(guān)它們的信息請(qǐng)參考相關(guān)文檔。
我注意到一些應(yīng)用程序，當(dāng)右鍵單擊其任務(wù)欄最小化按鈕時(shí)，在彈出的上下文菜單中具備特殊的命令。例如，WinAmp（一個(gè)流行的媒體播放器）有一個(gè)附加的 “WinAmp”菜單項(xiàng)，其中是 WinAmp 特有的命令。我如何在程序的任務(wù)欄按鈕中添加我自己的菜單項(xiàng)？
Jirair Osygian
我創(chuàng)建了一個(gè)簡單的 MFC SDI 程序，該程序用表單視圖（Form View）顯示一個(gè)計(jì)數(shù)器。我想通過右鍵單擊任務(wù)欄上程序的最小化按鈕來控制啟動(dòng)/停止這個(gè)計(jì)數(shù)器。在表單視圖上通過按鈕控制的啟動(dòng)/停止功能運(yùn)行正常，我也能將啟動(dòng)/停止命令加到系統(tǒng)菜單。但我單擊加入的系統(tǒng)菜單時(shí)沒反應(yīng)。我如何處理這些定制的系統(tǒng)菜單消息？
Monicque Sharman
我兩個(gè)問題一起回答，Jirair 問題的答案很簡單：當(dāng)你右鍵單擊任務(wù)欄上應(yīng)用程序的最小化按鈕時(shí)，用戶看到的菜單與用戶單擊左上角應(yīng)用程序標(biāo)題欄圖標(biāo)或按 Alt+Space 所看到的菜單一樣。如 Figure 1 所示。這個(gè)菜單被稱為系統(tǒng)菜單，其中包括命令如：還原、最小化、最大化和關(guān)閉等。
Figure 1 系統(tǒng)菜單
你可以調(diào)用 ::GetSystemMenu 來獲得此系統(tǒng)菜單，然后可以添加、刪除或修改菜單項(xiàng)。你甚至可以通過關(guān)掉 WS_SYSMENU 窗口創(chuàng)建式樣標(biāo)志或 PreCreateWindow 虛函數(shù)來完全屏蔽掉這個(gè)系統(tǒng)菜單。但不論你做什么，當(dāng)用戶右鍵單擊任務(wù)欄上應(yīng)用程序的最小化按鈕時(shí)，這個(gè)系統(tǒng)菜單還是會(huì)顯示出來的。
到了 Monicque 的問題：如果在系統(tǒng)菜單中添加自己的命令，MFC 是如何處理它們的呢？如果按常規(guī)來做 ——在某個(gè)地方寫一個(gè) ON_COMMAND 處理器并將它加到消息映射中，你會(huì)發(fā)現(xiàn)你的處理器不起作用，怎么會(huì)這樣呢？
那是因?yàn)?Windows 和 MFC 處理系統(tǒng)命令的方式與處理普通菜單命令的方式不一樣。當(dāng)用戶調(diào)用窗體中的常規(guī)菜單命令或按鈕時(shí)，Windows 向主窗口發(fā)送一個(gè) WM_COMMAND 消息。如果你使用 MFC，那么其命令路由機(jī)制將捕獲此消息并通過操作系統(tǒng)將它路由到該命令的 ON_COMMAND 命令處理器對(duì)象。（有關(guān) MFC 命令處理機(jī)制的詳細(xì)內(nèi)容，參見我在 MSJ 1995年7月發(fā)表的文章：“Meandering Through the Maze of MFC Message and Command Routing”）。
然而系統(tǒng)命令不屬于 WM_COMMAND 消息范圍。而屬于另外一個(gè)叫做——WM_SYSCOMMAND 的消息。不論命令I(lǐng)D是真正的系統(tǒng)命令如 SC_MINIMIZE 和 SC_CLOSE，還是你自己添加的其它命令I(lǐng)D都是如此。為了處理系統(tǒng)菜單命令，你必須處理顯式處理 WM_SYSCOMMAND 并且要選擇你自己的命令 IDs。這就需要你在主窗口消息映射中添加ON_WM_SYSCOMMAND，它有一個(gè)處理函數(shù)如下：
CMainFrame::OnSysCommand(UINT nID, LPARAM lp)
{
if (nID==ID_MY_COMMAND) {
... // 處理它
return 0;
}
// 傳遞到基類：這一步很重要!
return CFrameWnd::OnSysCommand(nID, lp);
} 如果該命令不是你的，不要忘了將它傳遞到你的基類處理——典型地，那就是 CFrameWnd 或 CMDIFrameWnd。否則，Windows 將無法得到此消息，并且會(huì)破壞內(nèi)建的命令。
在主框架中處理 WM_SYSCOMMAND 固然可以，但這樣做感覺太業(yè)余。為什么要用特殊的機(jī)制來處理呢？就因?yàn)樗鼈兪窍到y(tǒng)菜單嗎？如果你想在視圖或文檔對(duì)象中處理系統(tǒng)命令會(huì)怎樣呢？有一個(gè)常見的命令放到了系統(tǒng)菜單中，它就是“關(guān)于”（ID_APP_ABOUT），大多數(shù) MFC 程序都是在應(yīng)用程序?qū)ο笾刑幚?ID_APP_ABOUT：
void CMyApp::OnAppAbout()
{
static CAboutDialog dlg;
dlg.DoModal();
} MFC 一個(gè)真正很酷的特性是它的命令路由系統(tǒng)，它使得象 CMyApp 這樣的非窗口對(duì)象也能處理菜單命令。許多程序員甚至都不了解怎么會(huì)有這樣的例外。如果你已經(jīng)在應(yīng)用程序?qū)ο笾刑幚?ID_APP_ABOUT，那把ID_APP_ABOUT 添加到系統(tǒng)菜單后，為什么還要去實(shí)現(xiàn)一套單獨(dú)的機(jī)制？
處理外加系統(tǒng)命令的比較好的，或者說更 MFC 的方法應(yīng)該是通過常規(guī)的命令路由機(jī)制傳遞它們。然后按 MFC 常規(guī)方法編寫 ON_COMMAND 處理例程來處理系統(tǒng)命令。你甚至可以用 ON_UPDATE_COMMAND_UI 來更新你的系統(tǒng)菜單項(xiàng)，例如禁用某個(gè)菜單項(xiàng)或在菜單項(xiàng)旁邊顯示一個(gè)檢訖標(biāo)志。
Figure 2 是我寫的一個(gè)類，CSysCmdRouter，這個(gè)類將系統(tǒng)命令轉(zhuǎn)成常規(guī)命令。為了使用這個(gè)類，你要做的只是在主框架中實(shí)例化 CSysCmdRouter，并從 OnCreate 中調(diào)用其 Init 方法即可：
int CMainFrame::OnCreate(...)
{
// 將我的菜單項(xiàng)添加到系統(tǒng)菜單
CMenu* pMenu = GetSystemMenu(FALSE);
pMenu->AppendMenu(..ID_MYCMD1..);
pMenu->AppendMenu(..ID_MYCMD2..);
// 通過 MFC 路由系統(tǒng)命令
m_sysCmdHook.Init(this);
return 0;
} 一旦你調(diào)用 CSysCmdRouter::Init，你便可以按常規(guī)方式處理 ID_MYCMD1 和 ID_MYCMD2，為 MFC 命令路由機(jī)制中的任何對(duì)象編寫 ON_COMMAND 處理例程——視圖，文檔，框架，應(yīng)用程序或通過改寫 OnCmdMsg 添加的任何其它命令對(duì)象。CSysCmdRouter 還讓你用 ON_UPDATE_COMMAND_UI 處理器更新系統(tǒng)菜單。唯一要注意的是確保命令I(lǐng)Ds不要與其它菜單命令（除非他們確實(shí)代表相同的命令）或內(nèi)建系統(tǒng)命令發(fā)生沖突，內(nèi)建系統(tǒng)命令從 SC_SIZE = 0xF000 開始。Visual Studio .NET 指定的命令 IDs 從 0x8000 = 32768 開始，所以如果你讓 Visual Studio 來指定 IDs，只要不超過 0xF000-0x8000 = 0x7000 個(gè)命令即可。也就是十進(jìn)制的 28,762。如果你的應(yīng)用程序有超過 28000 個(gè)命令，那么你需要咨詢編程精神病專家。
CSysCmdRouter 是如何實(shí)現(xiàn)其魔法的呢？簡單：它使用我那個(gè)以前專欄中無處不在的 CSubclassWnd。CSubclassWnd 使你不用從其派生便能子類化 MFC 窗口對(duì)象。CSysCmdRouter 派生自 CSubclassWnd 并使用它子類化主框架。尤其是它截獲發(fā)送到框架的 WM_SYSCOMMAND 消息。如果命令 ID 屬于系統(tǒng)命令（大于 SC_SIZE = 0xF000），則 CSysCmdRouter 沿著 Windows 一路傳遞該消息；否則便吃掉 WM_SYSCOMMAND 并重新將它作為 WM_COMMAND 發(fā)送，于是 MFC 按照其常規(guī)路由過程，調(diào)用你的 ON_COMMAND 處理器。很聰明，是不是？
那么 ON_UPDATE_COMMAND_UI 處理器呢？CSysCmdRouter 是如何讓它處理系統(tǒng)菜單命令的呢？很簡單。就在 Windows 顯示菜單前，他向你的主窗口發(fā)送一個(gè) WM_INITMENUPOPUP 消息。這是你更新菜單項(xiàng)的最佳時(shí)機(jī)——啟用或禁用它們，添加檢訖標(biāo)志等等。MFC 為每個(gè)菜單項(xiàng)創(chuàng)建一個(gè) CCmdUI 對(duì)象并將它傳遞到你的消息映射中相應(yīng)的 ON_UPDATE_COMMAND_UI 處理器。以它為參數(shù)的 MFC 函數(shù)是 CFrameWnd::OnInitMenuPopup，這個(gè)函數(shù)是這樣的：
void CFrameWnd::OnInitMenuPopup(CMenu* pMenu, UINT nIndex, BOOL bSysMenu)
{
if (bSysMenu)
return; // don''t support system menu
...
} MFC 初始化系統(tǒng)菜單時(shí)不做任何事情。為什么要去關(guān)心這種事呢？萬一你要讓 bSysMenu 為 FALSE，即使是系統(tǒng)菜單，那該怎么辦？這恰恰是 CSysCmdRouter 做的事情。它截取 WM_INITMENUPOPUP 并清除 bSysMenu 標(biāo)志，也就是 LPARAM 的 HIWORD：
if (msg==WM_INITMENUPOPUP) {
lp = LOWORD(lp); // (set HIWORD = 0)
} 現(xiàn)在，當(dāng) MFC 獲得 WM_INITMENUPOPUP，它認(rèn)為該菜單是常規(guī)菜單。只要你的命令 IDs 與真正的系統(tǒng)菜單不沖突，一切都運(yùn)行得很好。如果你改寫 OnInitMenuPopup，唯一丟失的東西是不能從主窗口菜單中區(qū)分系統(tǒng)菜單。嘿，你不能什么都想要！通過改寫 CWnd::WindowProc，你總是能處理 WM_INITMENUPOPUP 的，或你想要區(qū)分，就比較 HMENUs。但你確實(shí)不用關(guān)心命令來自何處。
Figure 3 任務(wù)欄菜單
為了展示所有的實(shí)踐，我寫了一個(gè)小測(cè)試程序： TBMenu。如圖 Figure 3 所示，當(dāng)你右鍵單擊任務(wù)欄上 TBMenu 的最小化按鈕，便會(huì)顯示出菜單。你可以看到在菜單底部有兩個(gè)額外的命令。TBMenu 的 CMainFrame代碼如 Figure 4 所示。便知道在 OnCreate 的什么地方添加命令并在 CMainFrame 的消息映射中用 ON_COMMAND 以及 ON_UPDATE_COMMAND_UI 處理器處理它們。TBMenu 在其應(yīng)用程序類中處理 ID_APP_ABOUT（代碼未列出）。CSysCmdRouter 使系統(tǒng)命令的工作機(jī)制類似其它命令。
說到命令，我們來看看一個(gè)小資料：
在我一月份的專欄中，我問是否有人知道 Ctrl+Alt+Del 的由來。顯然，有幾個(gè)讀者知道如何使用 Google，因?yàn)樗麄儼l(fā)給我的是相同的鏈接：《今日美國》上的一篇文章：“Thank this guy for 'control-alt-delete'”，我在一月發(fā)問之前就發(fā)現(xiàn)了這篇文章。Ctrl+Alt+Del 是由一個(gè)名叫 David J. Bradley 的人發(fā)現(xiàn)的，他在 IBM 工作過。
IBM 覺得應(yīng)該有一種方法不用關(guān)閉電源就能重置（reset）其新的 PC 機(jī)。為什么要專門用 Ctrl+Alt+Del 這三個(gè)鍵呢？從技術(shù)上來說，David 需要使用兩個(gè)修飾鍵。他想要一種沒有人可能意外敲入的鍵組合。所以他選擇了
Ctrl+Alt 作為修飾鍵（比 Shift 用得少）和 Delete，此鍵位于鍵盤的另一端，所以敲擊 Ctrl+Alt+Del 需要兩只手，至少在過去是這樣做的。
當(dāng)今現(xiàn)代鍵盤在右邊也有 Ctrl 和 Alt 鍵。重啟特性的初衷是為 IBM 的人設(shè)計(jì)的秘密安全出口，但不可避免地，它已經(jīng)成為一個(gè)不是秘密的秘密。一旦開發(fā)人員知道了它，他們便開始告訴客戶使用這個(gè)特性來解決機(jī)器掛起問題。隨著歷史的發(fā)展，Ctrl+Alt+Del 被人們親切地成為“三指敬禮”，即便是在當(dāng)今的 Windows 中仍然具有生命力，用它調(diào)出任務(wù)管理器，以便你能殺死掛起的任務(wù)或終止系統(tǒng)（更多有關(guān)類似 Ctrl+Alt+Del 安全鍵序列的內(nèi)容，參見本月的 Security Briefs 專欄）。那么，如果 Ctrl+Alt+Del 失敗了怎么辦？為什么會(huì)失敗，請(qǐng)按住它保持 5 秒鐘。
David Bradley 是當(dāng)初建立 IBM 個(gè)人計(jì)算機(jī)的 12 個(gè)工程師之一。他編寫了 ROM BIOS，有關(guān) David 的簡介，參見 David J. Bradley。
祝編程愉快！
您的提問和評(píng)論可發(fā)送到 Paul 的信箱：cppqa@microsoft.com
作者簡介
Paul DiLascia 是一名自由作家，顧問和 Web/UI 設(shè)計(jì)者。他是《Writing Reusable Windows Code in C++》書（Addison-Wesley, 1992）的作者。通過 http://www.dilascia.com 可以獲得更多了解。
本文出自 MSDN Magazine 的 May 2005 期刊，可通過當(dāng)?shù)貓?bào)攤獲得，或者最好是 訂閱
本文來自CSDN博客，轉(zhuǎn)載請(qǐng)標(biāo)明出處：http://blog.csdn.net/liuchanghe/archive/2006/12/31/1471302.aspx