Unless I'm in the situation where the parameter is used in only debug or only release build, I tend to just comment out the parameter name.

I've also seen people just mention the variable name in the function body on a line by itself, without any cast.

hat is the best to use and why ?

The template version requires more work out of the compiler and doesn't really accomplish anything extra. In general, I'd lean towards avoiding the template version unless you can qualify exactly what benefit you get from it. The template version is also technically generating a function call which can have a big runtime overhead in some build configuration, though that's not likely to be relevant to this use case.

A macro can of course forward to a template if things like ICC requires it. It's very common to put all the definitions for things like UNUSED_PARAM into a header file that has a bunch of compiler/platform detection (or uses a configuration header that has that pre-generated) to use the most appropriate implementation, as some of these things will vary heavily by compiler or platform.

Remember, C++ as a language has absolutely no notion of an unused variable warning. That's something that compilers add on to try to be helpful. Because it's not part of C++, there's no standard on how those warnings work or how they should be suppressed. As with most anything that isn't firmly locked down and etched in stone, there isn't a single "best" way to do it.

Another option I'm somewhat in favor of is to just turn off the unused parameter warning. I haven't seen it actually be useful in solving either a correctness or a performance problem in... well, ever that I can recall.

The template you posted would itself cause a slightly different warning on one compiler I use, as it is itself a function with an unused argument.

void FunkySmell( int _iUnused ) {
}
// Warning, unused parameter.

void FunkySmell( int _iUnused ) {
    static_cast<void>(_iUnused);
}
// Warning, useless statement (no side-effect).

void FunkySmell( int /*_iUnused*/ ) {
}
// Correct.

L. Spiro

void FunkySmell( int _iUnused ) {
}
// Warning, unused parameter.

void FunkySmell( int _iUnused ) {
    static_cast<void>(_iUnused);
}
// Warning, useless statement (no side-effect).

void FunkySmell( int /*_iUnused*/ ) {
}
// Correct.

L. Spiro

The 3rd is my favorite too, but... on one of the compilers we use, the 3rd one also produces a warning (unused unnamed argument).
Our solution is:
(void)(_iUnused);

or: #define UNUSED(x) ((void)(x))
...which AFAIK doesn't cause any no-side-effect warnings.

I see.
But I am fairly sure (entirely open to correction) that your cast produces the same result as my static cast, which generates a warning in Xcode.
No matter what, Coverity is going to flag these things.


I’m not sure of any way to avoid these kinds of warnings entirely (and we are not having a discussion on why we are putting “useless” parameters into functions because there are so many legitimate reasons why it happens), so your best bet is just to figure out what reduces the number of warnings you yourself get while compiling.

Hodgman and I have our favorite ways. They don’t always eliminate the problems, especially when you are supporting lots of platforms or even just overloading operator new. Right now your best course of action is simply to do what it takes to remove the warnings that you are encountering. I stand by my proposal, but I literally don’t think any course of action will pacify every compiler out there. For now it makes more sense to just do what pacifies most of them, and if you encounter some remaining issues then ask again, specifying which compiler you are using and what warning you aim to avoid.

L. Spiro

and we are not having a discussion on why we are putting “useless” parameters into functions because there are so many legitimate reasons why it happens

I'm not sure I buy the 'legitimate' part of that. As I see it, there are usually two cases where we end up with unused parameters:

• When the implementation has changed such that the public API no longer accurately reflects the provided functionality.
• When you abuse polymorphism such that a child must override a parent method to do something unrelated.

Neither of those are particularly legitimate - the former can be addressed via deprecation, and the latter by refactoring.