UNREFERENCED_PARAMETER的做用

UNREFERENCED_PARAMETER 的做用
2007年06月16日 星期六 14:38
咱们从 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 选项我没有在本文讨论。有关它们的信息请参考相关文档。