我看到過一些 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 選項我沒有在本文討論。有關它們的信息請參考相關文檔。
我注意到一些應用程序，當右鍵單擊其任務欄最小化按鈕時，在彈出的上下文菜單中具備特殊的命令。例如，WinAmp（一個流行的媒體播放器）有一個附加的 “WinAmp”菜單項，其中是 WinAmp 特有的命令。我如何在程序的任務欄按鈕中添加我自己的菜單項？
Jirair Osygian
我創建了一個簡單的 MFC SDI 程序，該程序用表單視圖（Form View）顯示一個計數器。我想通過右鍵單擊任務欄上程序的最小化按鈕來控制啟動/停止這個計數器。在表單視圖上通過按鈕控制的啟動/停止功能運行正常，我也能將啟動/停止命令加到系統菜單。但我單擊加入的系統菜單時沒反應。我如何處理這些定制的系統菜單消息？
Monicque Sharman
我兩個問題一起回答，Jirair 問題的答案很簡單：當你右鍵單擊任務欄上應用程序的最小化按鈕時，用戶看到的菜單與用戶單擊左上角應用程序標題欄圖標或按 Alt+Space 所看到的菜單一樣。如 Figure 1 所示。這個菜單被稱為系統菜單，其中包括命令如：還原、最小化、最大化和關閉等。
Figure 1 系統菜單
你可以調用 ::GetSystemMenu 來獲得此系統菜單，然後可以添加、刪除或修改菜單項。你甚至可以通過關掉 WS_SYSMENU 窗口創建式樣標志或 PreCreateWindow 虛函數來完全屏蔽掉這個系統菜單。但不論你做什麼，當用戶右鍵單擊任務欄上應用程序的最小化按鈕時，這個系統菜單還是會顯示出來的。
到了 Monicque 的問題：如果在系統菜單中添加自己的命令，MFC 是如何處理它們的呢？如果按常規來做 ——在某個地方寫一個 ON_COMMAND 處理器並將它加到消息映射中，你會發現你的處理器不起作用，怎麼會這樣呢？
那是因為 Windows 和 MFC 處理系統命令的方式與處理普通菜單命令的方式不一樣。當用戶調用窗體中的常規菜單命令或按鈕時，Windows 向主窗口發送一個 WM_COMMAND 消息。如果你使用 MFC，那麼其命令路由機制將捕獲此消息並通過操作系統將它路由到該命令的 ON_COMMAND 命令處理器對象。（有關 MFC 命令處理機制的詳細內容，參見我在 MSJ 1995年7月發表的文章：“Meandering Through the Maze of MFC Message and Command Routing”）。
然而系統命令不屬於 WM_COMMAND 消息范圍。而屬於另外一個叫做——WM_SYSCOMMAND 的消息。不論命令ID是真正的系統命令如 SC_MINIMIZE 和 SC_CLOSE，還是你自己添加的其它命令ID都是如此。為了處理系統菜單命令，你必須處理顯式處理 WM_SYSCOMMAND 並且要選擇你自己的命令 IDs。這就需要你在主窗口消息映射中添加ON_WM_SYSCOMMAND，它有一個處理函數如下：CMainFrame::OnSysCommand(UINT nID, LPARAM lp)
{
if (nID==ID_MY_COMMAND) {
... // 處理它
return 0;
}
// 傳遞到基類：這一步很重要!
return CFrameWnd::OnSysCommand(nID, lp);
}
如果該命令不是你的，不要忘了將它傳遞到你的基類處理——典型地，那就是 CFrameWnd 或 CMDIFrameWnd。否則，Windows 將無法得到此消息，並且會破壞內建的命令。
在主框架中處理 WM_SYSCOMMAND 固然可以，但這樣做感覺太業余。為什麼要用特殊的機制來處理呢？就因為它們是系統菜單嗎？如果你想在視圖或文檔對象中處理系統命令會怎樣呢？有一個常見的命令放到了系統菜單中，它就是“關於”（ID_APP_ABOUT），大多數 MFC 程序都是在應用程序對象中處理 ID_APP_ABOUT：
void CMyApp::OnAppAbout()
{
static CAboutDialog dlg;
dlg.DoModal();
}
MFC 一個真正很酷的特性是它的命令路由系統，它使得象 CMyApp 這樣的非窗口對象也能處理菜單命令。許多程序員甚至都不了解怎麼會有這樣的例外。如果你已經在應用程序對象中處理 ID_APP_ABOUT，那把ID_APP_ABOUT 添加到系統菜單後，為什麼還要去實現一套單獨的機制？
處理外加系統命令的比較好的，或者說更 MFC 的方法應該是通過常規的命令路由機制傳遞它們。然後按 MFC 常規方法編寫 ON_COMMAND 處理例程來處理系統命令。你甚至可以用 ON_UPDATE_COMMAND_UI 來更新你的系統菜單項，例如禁用某個菜單項或在菜單項旁邊顯示一個檢訖標志。
Figure 2 是我寫的一個類，CSysCmdRouter，這個類將系統命令轉成常規命令。為了使用這個類，你要做的只是在主框架中實例化 CSysCmdRouter，並從 OnCreate 中調用其 Init 方法即可：
int CMainFrame::OnCreate(...)
{
// 將我的菜單項添加到系統菜單
CMenu* pMenu = GetSystemMenu(FALSE);
pMenu->AppendMenu(..ID_MYCMD1..);
pMenu->AppendMenu(..ID_MYCMD2..);
// 通過 MFC 路由系統命令
m_sysCmdHook.Init(this);
return 0;
}
一旦你調用 CSysCmdRouter::Init，你便可以按常規方式處理 ID_MYCMD1 和 ID_MYCMD2，為 MFC 命令路由機制中的任何對象編寫 ON_COMMAND 處理例程——視圖，文檔，框架，應用程序或通過改寫 OnCmdMsg 添加的任何其它命令對象。CSysCmdRouter 還讓你用 ON_UPDATE_COMMAND_UI 處理器更新系統菜單。唯一要注意的是確保命令IDs不要與其它菜單命令（除非他們確實代表相同的命令）或內建系統命令發生沖突，內建系統命令從 SC_SIZE = 0xF000 開始。Visual Studio .NET 指定的命令 IDs 從 0x8000 = 32768 開始，所以如果你讓 Visual Studio 來指定 IDs，只要不超過 0xF000-0x8000 = 0x7000 個命令即可。也就是十進制的 28,762。如果你的應用程序有超過 28000 個命令，那麼你需要咨詢編程精神病專家。
CSysCmdRouter 是如何實現其魔法的呢？簡單：它使用我那個以前專欄中無處不在的 CSubclassWnd。CSubclassWnd 使你不用從其派生便能子類化 MFC 窗口對象。CSysCmdRouter 派生自 CSubclassWnd 並使用它子類化主框架。尤其是它截獲發送到框架的 WM_SYSCOMMAND 消息。如果命令 ID 屬於系統命令（大於 SC_SIZE = 0xF000），則 CSysCmdRouter 沿著 Windows 一路傳遞該消息；否則便吃掉 WM_SYSCOMMAND 並重新將它作為 WM_COMMAND 發送，於是 MFC 按照其常規路由過程，調用你的 ON_COMMAND 處理器。很聰明，是不是？
那麼 ON_UPDATE_COMMAND_UI 處理器呢？CSysCmdRouter 是如何讓它處理系統菜單命令的呢？很簡單。就在 Windows 顯示菜單前，他向你的主窗口發送一個 WM_INITMENUPOPUP 消息。這是你更新菜單項的最佳時機——啟用或禁用它們，添加檢訖標志等等。MFC 為每個菜單項創建一個 CCmdUI 對象並將它傳遞到你的消息映射中相應的 ON_UPDATE_COMMAND_UI 處理器。以它為參數的 MFC 函數是 CFrameWnd::OnInitMenuPopup，這個函數是這樣的：
void CFrameWnd::OnInitMenuPopup(CMenu* pMenu, UINT nIndex, BOOL bSysMenu)
{
if (bSysMenu)
return; // don''t support system menu
...
}
MFC 初始化系統菜單時不做任何事情。為什麼要去關心這種事呢？萬一你要讓 bSysMenu 為 FALSE，即使是系統菜單，那該怎麼辦？這恰恰是 CSysCmdRouter 做的事情。它截取 WM_INITMENUPOPUP 並清除 bSysMenu 標志，也就是 LPARAM 的 HIWORD：
if (msg==WM_INITMENUPOPUP) {
lp = LOWORD(lp); // (set HIWORD = 0)
}
現在，當 MFC 獲得 WM_INITMENUPOPUP，它認為該菜單是常規菜單。只要你的命令 IDs 與真正的系統菜單不沖突，一切都運行得很好。如果你改寫 OnInitMenuPopup，唯一丟失的東西是不能從主窗口菜單中區分系統菜單。嘿，你不能什麼都想要！通過改寫 CWnd::WindowProc，你總是能處理 WM_INITMENUPOPUP 的，或你想要區分，就比較 HMENUs。但你確實不用關心命令來自何處。
Figure 3 任務欄菜單
為了展示所有的實踐，我寫了一個小測試程序： TBMenu。如圖 Figure 3 所示，當你右鍵單擊任務欄上 TBMenu 的最小化按鈕，便會顯示出菜單。你可以看到在菜單底部有兩個額外的命令。TBMenu 的 CMainFrame代碼如 Figure 4 所示。便知道在 OnCreate 的什麼地方添加命令並在 CMainFrame 的消息映射中用 ON_COMMAND 以及 ON_UPDATE_COMMAND_UI 處理器處理它們。TBMenu 在其應用程序類中處理 ID_APP_ABOUT（代碼未列出）。CSysCmdRouter 使系統命令的工作機制類似其它命令。
說到命令，我們來看看一個小資料：
在我一月份的專欄中，我問是否有人知道 Ctrl+Alt+Del 的由來。顯然，有幾個讀者知道如何使用 Google，因為他們發給我的是相同的鏈接：《今日美國》上的一篇文章：“Thank this guy for 'control-alt-delete'”，我在一月發問之前就發現了這篇文章。Ctrl+Alt+Del 是由一個名叫 David J. Bradley 的人發現的，他在 IBM 工作過。
IBM 覺得應該有一種方法不用關閉電源就能重置（reset）其新的 PC 機。為什麼要專門用 Ctrl+Alt+Del 這三個鍵呢？從技術上來說，David 需要使用兩個修飾鍵。他想要一種沒有人可能意外敲入的鍵組合。所以他選擇了
Ctrl+Alt 作為修飾鍵（比 Shift 用得少）和 Delete，此鍵位於鍵盤的另一端，所以敲擊 Ctrl+Alt+Del 需要兩只手，至少在過去是這樣做的。
當今現代鍵盤在右邊也有 Ctrl 和 Alt 鍵。重啟特性的初衷是為 IBM 的人設計的秘密安全出口，但不可避免地，它已經成為一個不是秘密的秘密。一旦開發人員知道了它，他們便開始告訴客戶使用這個特性來解決機器掛起問題。隨著歷史的發展，Ctrl+Alt+Del 被人們親切地成為“三指敬禮”，即便是在當今的 Windows 中仍然具有生命力，用它調出任務管理器，以便你能殺死掛起的任務或終止系統（更多有關類似 Ctrl+Alt+Del 安全鍵序列的內容，參見本月的 Security Briefs 專欄）。那麼，如果 Ctrl+Alt+Del 失敗了怎麼辦？為什麼會失敗，請按住它保持 5 秒鐘。
David Bradley 是當初建立 IBM 個人計算機的 12 個工程師之一。他編寫了 ROM BIOS，有關 David 的簡介，參見 David J. Bradley。
祝編程愉快！
您的提問和評論可發送到 Paul 的信箱：[email protected]
本文配套源碼
