2

So I've seen a number of threads explaining how to avoid unreferenced parameter warnings, for instance:

Avoid warning 'Unreferenced Formal Parameter'
C++ What is the purpose of casting to void?

But what I'm wondering is whether the compiler will do anything different based on which approach is used. For example, will the compiled output for the following three situations be any different?

void Method(int /*x*/)
{
    // Parameter is left unnamed
}

void Method(int x)
{
    x;  // This would be the same as UNREFERENCED_PARAMETER(x);
}

void Method(int x)
{
    (void)x;  // This would be the same as _CRT_UNUSED(x);
}

I'm most interested in this from the standpoint of what the compiler will do, but if you feel strongly for one approach over the others, I'm happy to hear those arguments as well.

Community
  • 1
  • 1
FrolickingFerret
  • 291
  • 1
  • 2
  • 12
  • Interestingly enough, I'm now wondering if option 1 will allow optimizations for objects such as smart pointers where normally a constructor/destructor pair is called. This won't generate an unreferenced parameter warning, but I wonder if commenting out the parameter will avoid these calls. Away from my compiler (AFC) at the moment, but if I remember later I'll test this. – FrolickingFerret May 02 '13 at 03:52

2 Answers2

2

Of the three, the last option, (void)x; is preferable in most cases.

The first option, leaving the parameter unnamed, is acceptable, but often it is useful for the parameter to have a name for debugging purposes (e.g., even if you aren't using the parameter in the function, you might be interested in its value when debugging). There are cases where this option is fine, though, e.g. when doing tag dispatching.

The second option, x; may cause other warnings. Visual C++ will issue warning C4555 for this code:

warning C4555: expression has no effect; expected expression with side-effect

By casting x to void via (void)x;, this warning is suppressed. (Note that this warning is off by default; this warning must be expressly enabled via #pragma or command-line option.)

James McNellis
  • 348,265
  • 75
  • 913
  • 977
  • Thanks, it is definitely good to know that option 2 can possibly generate other warnings. So +1 for option 3 in that regard, though this isn't exactly performance-related. – FrolickingFerret Apr 25 '13 at 06:08
0

I can see no reason why the compiler would treat any of those different. But the only way to tell for sure for your compiler is for you to look at the output of your compiler.

I would prefer the first option since this situation (unused parameters) is what that language feature was designed for.

john
  • 85,011
  • 4
  • 57
  • 81
  • Thanks, and I can definitely check for the compiler that I use. The reason I'm asking on here is partially to see if anyone says "No! Don't use option N! That will do bad things on such and such compiler." I also prefer option 1 in general, but am currently leaning toward UNREFERENCED_PARAMETER because I'm using the Microsoft VC++ compiler and have quite a few situations where the parameters are used in asserts or debug-only code. – FrolickingFerret Apr 14 '13 at 20:59
  • I like James' answer a lot as well, but this one is more aligned with the performance aspect of my question. – FrolickingFerret Mar 29 '16 at 06:20