UNREFERENCED_ The role of parameter_ Let’s start with parameter. This macro is defined in WinNT. H as follows:
?Define unreferenced_ Parameter (P) (P)
in other words, unreferenced_ Parameter expands the parameter or expression passed. The purpose is to avoid compiler warnings about unreferenced parameters. Many programmers, including myself, like to compile with the highest level warning level 4 (/ W4). Level 4 belongs to the category of “events that can be ignored by security”. While they may embarrass you, they rarely break your code. For example, there may be lines of code in your program:

int x=1; the problem is that level 4 pays too much attention to details. On level 4, the compiler has to complain about such innocuous things as not referencing the parameter (unless, of course, you really want to use the parameter intentionally, and then it’s OK). Suppose you have a function with two arguments, 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 stops when it compiles your function that references arg2. And because of the statement:

arg2;
in fact, if you don’t do anything, the compiler won’t generate any code for it, so there won’t be any loss in space and performance

Careful people may ask: since you don’t use arg2, why did you declare it in the first place?It’s usually because you implement a function to meet the signature requirements inherent in some APIs. For example, the signature of the onsize processing routine in MFC must look like this:

void OnSize(UINT nType, int cx, int cy);
here CX/CY is the new width/height of the window, and ntype is similar to size_ Maximized or size_ A code like restored indicates whether the window is maximized or normal size. Generally, you don’t care about ntype, just 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 program based on windows without encountering unreferenced parameters
so much has been said about unreferenced_ Parameter content. Judy also mentioned in her question another C + + programmer’s common use and its role is unreferenced_ The same trick of parameter is to comment the parameter name in the function signature

Void cmywnd:: onsize (uint/* ntype * /, int CX, int CY) {}
now ntype is an unnamed parameter, which has the same effect as typing onsize (uint, int CX, int CY). Now the key question is: which method should you use – unnamed parameter or unreferenced_ PARAMETER？
in most cases, there is no difference between the two, which one to use is purely a matter of style（ Do you like your coffee black or cream But I think unreferenced must be used in at least one case_ PARAMETER。 Suppose you decide that windows are not allowed to be maximized. Then you can disable the maximize button, remove it from the system menu, and prevent each user from maximizing the operation of the window. Because you’re paranoid (most good programmers are paranoid), you add an assert to make sure the code works as you want it to:

void CMyWnd::OnSize(UINT nType, int cx, int cy){ ASSERT(nType != SIZE_ MAXIMIZE); … // Use CX, cy}
the quality inspection team tries its best to run your program in various ways, and assert never pops up, so you think it is safe to compile and generate the release version. But at this point_ There is no debug definition, assert (ntype= SIZE_ Maximum) is expanded to ((void) 0), and ntype becomes an unreferenced parameter! So get into your clean compilation. You can’t comment out the ntype in the parameter table because you want to use it in assert. So in this case – the only place you use parameters is in assert or something else_ Debug condition code – only unreferenced_ Parameter keeps the compiler in debug and release generation mode. Do you know
before concluding, I think there is another problem I didn’t mention, that is, you can suppress a single compiler warning with the pragma instruction as follows:

#Pragma warning (disable: 4100)
4100 is an error code that does not reference parameters. Pragma suppresses this warning for the rest of the files/modules. You can re enable this warning in the following ways:

#Pragma warning (default: 4100)
anyway, a better way is to save all the warning states before disabling a specific warning, and then return to the previous configuration after you finish. That way, you will return to the previous state, which is not necessarily the default state of the compiler

#Pragma warning (push) # pragma warning (disable: 4100) void somefunction (…) {} # pragma warning (POP)
of course, this method is rather lengthy for unreferenced parameters, but it may not be the case for other types of warnings. Library producers use # pragma warning to block warnings, so that their code can be compiled cleanly with/W4. MFC is full of such pragmas instructions. There are a lot of “pragma warning” options that I haven’t discussed in this article. For information about them, please refer to the relevant documentation