I have a super class like this:
class Parent { public: virtual void Function(int param); }; void Parent::Function(int param) { std::cout << param << std::endl; }
..and a sub-class like this:
class Child : public Parent { public: void Function(int param); }; void Child::Function(int param) { ;//Do nothing }
When I compile the sub-class .cpp file, I get this error
warning C4100: 'param' : unreferenced formal parameter
As a practice, we used to treat warnings as errors. How to avoid the above warning?
Thanks.
“Unreferenced formal parameter” is how Visual C++ calls a named function parameter that you don’t use inside the function. Similar warnings exist for other unused things, like an unused local variable. GCC and Clang actually use the word “unused” in their warning messages. Do not ignore the warning.
With /W4, the compiler complains: "warning C4100: 'arg2' : unreferenced formal parameter." To fool the compiler, you can add UNREFERENCED_PARAMETER (arg2). Now your function references arg2 so the compiler will shut up. And since the statement
Of course, that's way too verbose for unreferenced parameters, but possibly necessary for other kinds of warnings. Library builders use #pragma warning all the time to block warnings so their code can compile cleanly with /W4. MFC is full of such pragmas. There're even more #pragma warning options I haven't mentioned.
This macro is defined in winnt.h, like so: In other words, UNREFERENCED_PARAMETER expands to the parameter or expression passed. Its purpose is to avoid compiler warnings about unreferenced parameters. Many programmers, including yours truly, like to compile with the highest warning level, Level 4 (/W4).
In C++ you don't have to give a parameter that you aren't using a name so you can just do this:
void Child::Function(int) { //Do nothing }
You may wish to keep the parameter name in the declaration in the header file by way of documentation, though. The empty statement (;
) is also unnecessary.
I prefer using a macro, as it tells not only the compiler my intention, but other maintainers of the code, and it's searchable later on.
The method of commenting out the argument name can easily be missed by people unfamiliar with the code (or me 6 months later).
However, it's a style-issue, neither method is "better" or more optimal with regards to code generated, performance or robustness. To me, the deciding factor is informing others of my intent through a standardized system. Omitting the parameter name and putting in a comment would work equally well:
void CFooBar::OnLvnItemchanged(NMHDR *pNMHDR, LRESULT *pResult) { UNREFERENCED_PARAMETER(pNMHDR);
Alternatively:
void CFooBar::OnLvnItemchanged(NMHDR* /* pNMHDR */, LRESULT *pResult) { // Not using: pNMHDR
I would say that the worst solution is suppressing the warning message; that that will affect your entire file or project, and you'll lose the knowledge that maybe you've missed something. At least by adding the macro, or commenting out the argument name, you've told others that you've made a conscious decision to not use this argument and that it's not a mistake.
The Windows SDK in WinNT.h defines UNREFERENCED_PARAMETER()
along with DBG_UNREFERENCED_PARAMETER()
and DBG_UNREFERENCED_LOCAL_VARIABLE()
. They all evaluate to the same thing, but the difference is that DBG_UNREFERENCED_PARAMETER() is used when you are starting out and expect to use the parameter when the code is more complete. When you are sure you'll never use the parameter, use the UNREFERENCED_PARAMETER() version.
The Microsoft Foundation Classes (MFC) have a similar convention, with the shorter UNUSED()
and UNUSED_ALWAYS()
macros.
Pick a style and stick with it. That way later on you can search for "DBG_UNREFERENCED_PARAMETER
" in your code and find any instances of where you expected to use a argument, but didn't. By adopting a consistent style, and habitually using it, you'll make it easier for other and yourself later on.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With