C++:unreferenced_parameter usage

Original address:http://www.cnblogs.com/kex1n/archive/2010/08/05/2286486.html

Role: Tell the compiler that the variable is already in use and do not have to detect the warning!

Under the VC compiler, if you compile at the highest level, the compiler will very harshly point to your very small warning. When you have a variable in your life, and you are not using it, the compiler will report a warning:

"Warning C4100: ' xxxx ': unreferenced formal parameter."

So, in order for the compiler to not have to detect your warnings, use the Unreferenced_parameter statement. Like what:

int SomeFunction (int arg1, int arg2)
{
Unreferenced_parameter (ARG2)
...
}

I've seen some C + + code with Unreferenced_parameter for unused parameters, such as:

int SomeFunction (int arg1, int arg2) {  unreferenced_parameter (arg2) ...  }

I've also seen code like this:

int SomeFunction (int arg1, INT/* ARG2 */) {  ...}

Can you explain the difference? Which one is better to use? Let's start with the Unreferenced_parameter. This macro is defined in WinNT.h as follows:

#define Unreferenced_parameter (P) (p)

In other words, Unreferenced_parameter expands the passed arguments or expressions. The goal is to avoid the compiler's warning about unreferenced parameters. Many programmers, including me, like to compile with the highest level of warning levels 4 (/W4). Level 4 falls within the category of "events that can be safely ignored". Although they may embarrass you, it rarely destroys your code. For example, there might be some lines of code in your program:

int x=1;

But you've never been to X. Maybe this is what you left behind when you used X, only the code that used it was deleted, and you forgot to delete the variable. Warning Level 4 can find these little problems. So why not let the compiler help you finish perhaps the highest level of specialization? Compiling with Level 4 is a way to show your attitude to work. If you're writing a library for public users, level 4 is a social etiquette requirement. You don't want to force your developers to cleanly compile their code with low-level options.
The problem is that level 4 is just too much of a detail, and the compiler has to complain about the innocuous things that are not referenced by the parameter on the 4, unless, of course, you really want to use this parameter. Suppose you have a function that brings two parameters, but you only use one of them:

int SomeFunction (int arg1, int arg2) {    return arg1+5;}

Using/W4, the compiler complains:

"Warning C4100: ' arg2 ': unreferenced formal parameter."

In order to cheat the compiler, you can add Unreferenced_parameter (arg2). Now the compiler will shut up when compiling your reference arg2 function. And because of the statement:

arg2;

Without actually doing anything, the compiler does not generate any code for it, so there is no loss of space or performance.

The attentive person may ask: since you don't use arg2, why did you declare it? Usually because you implement a function to satisfy the inherent attribution needs of certain APIs, for example, the OnSize processing routine of MFC must be named as follows:

void OnSize (UINT nType, int cx, int cy);

Here Cx/cy is the new width/height of the window, NType is a code similar to size_maximized or size_restored, indicating whether the window is maximized or regular size. Generally you don't care about NType, only the CX and XY. So if you want to use/W4, you have to use Unreferenced_parameter (NType). OnSize is just one of thousands of MFC and Windows functions. It is almost impossible to write a Windows-based program without encountering unreferenced parameters.
Said so much about the unreferenced_parameter content. Judy also mentions in her question that another C + + programmer uses the same trick as Unreferenced_parameter, which is the name of the parameter in the signature of the annotation function:

void Cmywnd::onsize (UINT/* NType */, int cx, int cy) {}

Now NType is an unnamed parameter, and it works just like you typed OnSize (UINT, int cx, int cy). So the key question now is: Which method should you use--unnamed parameter, or Unreferenced_parameter?
In most cases, there is no difference between the two, which is purely a matter of style. (Do you like the color of your Java coffee in black or cream?) But I think there is at least one case where unreferenced_parameter must be used. Suppose you decide that the window is not allowed to maximize. Then you can disable the Maximize button, remove it from the system menu, and prevent each user from maximizing the action of the window. Because you are paranoid (most good programmers are paranoid), you add an assert (assertion) to ensure that the code runs as you intended:

void Cmywnd::onsize (UINT nType, int cx, int cy) {    ASSERT (nType! = size_maximize);    ...//Use CX, CY}

The QC team does everything in its ability to run your program in a variety of ways, and the ASSERT never pops up, so you think compiling the release version is safe. But at this point the _DEBUG definition is gone, and the ASSERT (nType! = size_maximize) expands to ((void) 0), and NType suddenly becomes an unreferenced parameter! So get into your clean compilation. You cannot comment out the NType in the parameter table because you want to use it in the ASSERT. So in this case--the only place where you use parameters is in ASSERT or in other _DEBUG condition code--only Unreferenced_parameter will keep the compiler in DEBUG and Release generation mode without problems. You got that?
Before concluding the discussion, I think there is one more question I have not mentioned, which is that you can suppress a single compiler warning with the pragma directive as follows:

#pragma warning (disable:4100)

4100 is an error code for unreferenced parameters. pragma suppress this warning from the remaining files/modules. You can re-enable this warning in the following ways:

#pragma warning (default:4100)

However, it's a good practice to save all warning states before disabling specific warnings, and then go back to the previous configuration when you're done. That way, you go back to the previous state, which is not necessarily the default state of the compiler.
So you can suppress an unreferenced parameter warning for a single function before and after the code with the pragma directive, as follows:

#pragma warning (push) #pragma warning (disable:4100) void SomeFunction (...) {} #pragma warning (pop)

Of course, this approach is tedious for unreferenced parameters, but it may not be the case for other types of warnings. Library generators Use the #pragma warning to block warnings so their code can be cleaned and compiled with/W4. MFC is full of such pragmas instructions. There are a lot of #pragma warning options I haven't discussed in this article. Please refer to the relevant documentation for information about them.

C++:unreferenced_parameter usage