Role of unreferenced_parameter

Let's start with unreferenced_parameter. This macro is defined in winnt. h as follows:

#define UNREFERENCED_PARAMETER(P) (P)

In other words, unreferenced_parameter expands the passed parameter or expression. The purpose is to prevent the compiler from warning about unreferenced parameters. Many programmers, including me, prefer to compile with the highest level warning level 4 (/W4. Level 4 belongs to the scope of "events that can be safely ignored. Although they may embarrass you, they seldom corrupt your code. For example, there may be some code lines in your program:

int x=1;

But you have never used X. Maybe this line was left behind when you used X before. You only deleted the code that used it and forgot to delete the variable. Warning Level 4 can find these minor issues. So, why not let the compiler help you achieve the highest level of specialization? Compiling with Level 4 is a way to show your work attitude. If you write a library for public users, Level 4 is required for social etiquette. You don't want to force your developers to use low-level options to cleanly compile their code.
The problem is that level 4 really pays too much attention to the details. on Level 4, the compiler will complain about anything that does not reference a parameter (unless you are really interested in using 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;}

When using/W4, the compiler complains:

“warning C4100: ''arg2'' : unreferenced formal parameter.”

To cheat the compiler, you can add unreferenced_parameter (arg2 ). Now the compiler will shut down when compiling your function that references arg2. And because of the statement:

arg2;

In fact, the compiler will not generate any code for it, so there will be no loss in space and performance.
Careful people may ask: Since you do not use arg2, why should you declare it? It is usually because you implement a function to meet the inherent signature requirements of Some APIs. For example, the onsize processing routine of MFC must be like the following:

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

Here, CX/Cy is the new width/height of the window, and ntype is an encoding similar to size_maximized or size_restored, indicating whether the window is maximized or the regular size. Generally, you don't care about ntype, but only focus on CX and XY. So if you want to use/W4, you must use unreferenced_parameter (ntype ). Onsize is only one of thousands of MFC and Windows functions. Writing a Windows-based program makes it almost impossible to encounter unreferenced parameters.
So much about unreferenced_parameter. In her question, Judy also mentioned another common C ++ programmer and its role is the same as that of unreferenced_parameter, that is, the parameter name in the annotation function signature:

void CMyWnd::OnSize(UINT /* nType */, int cx, int cy){}

Now ntype is an unnamed parameter, and the effect is the same as if you typed 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 is purely a style issue. (Do you like your java coffee in black or cream color ?) However, I think at least one case must use unreferenced_parameter. Suppose you decide that the window cannot be maximized. You can disable the maximize button to delete it from the system menu and prevent each user from maximizing the window. Because you are paranoid (most good programmers are paranoid), you add an assert to ensure that the code runs according to your intent:

void CMyWnd::OnSize(UINT nType, int cx, int cy){     ASSERT(nType != SIZE_MAXIMIZE);     ... // use cx, cy}

The QA Team has tried its best to run your program in various ways. The assert has never been popped up, so you think it is safe to compile the release version. However, the _ debug definition does not exist at this time. Assert (ntype! = Size_maximize) expands to (void) 0), and ntype becomes an unreferenced parameter at once! In this way, you can perform a clean compilation. You cannot comment out the ntype In the parameter table because you need to use it in assert. In this case, the only parameter you use is in assert or other _ debug condition code. Only unreferenced_parameter will keep the compiler in debug and release generation modes. Do you know?
Before closing the discussion, I think there is another problem I did not mention, that is, you can use the Pragma command to suppress a single compiler warning as follows:

#pragma warning( disable : 4100 )

4100 is an error code that does not reference parameters. Pragma suppresses the warning of other files/modules. You can use the following method to re-enable this warning:
#pragma warning( default : 4100 )
In any case, it is better to save all the warning States before disabling a specific warning, and then return to the previous configuration after you finish. In this way, you will return to the previous state, which is not necessarily the default state of the compiler.
So you can use the Pragma command to suppress the unreferenced parameter warning of a single function before and after the Code as follows:
#pragma warning( push ) #pragma warning( disable : 4100 )void SomeFunction(...){}#pragma warning( pop )
Of course, this method is not lengthy for parameters not referenced, but it may not be the case for other types of warnings. Library builders use # pragma warning to block warnings so that their code can be cleaned and compiled with/w4. MFC is full of such pragmas commands. There are many other # pragma warning options that I have not discussed in this article. For more information, see related documents.