Need your experience: is "(void)param;" to avoid unused variablewarnings well known for you?

[Qi]

Hi all,

Let me show some code first,

void someFunction(int param)
{
(void)param; // param is not used in this function. This line is
// just to silence the compiler warning about unused param.
}

Please note the "(void)param".
Is that usage common or well known for you?
Or you rarely saw it? Or even it's weird to you?

Just your experience is enough, no need to debate for it's good
or bad.

The reason I ask this is, in my another thread, some very veteran
C++ developers said they rarely saw that kind of usage.
That makes me a little nervous because I used it a lot in my
code to *improve* the code readability.
If it's not well known trick then it reduces code readability
and then I'm going to change my code about that.

That's not only about coding style but also about code readability.

Looking forward to hearing your experience.

Thanks

 

[goran.pusic]

Hi all,

Let me show some code first,

void someFunction(int param)
{
(void)param; // param is not used in this function. This line is
// just to silence the compiler warning about unused param.
}

Please note the "(void)param".
Is that usage common or well known for you?
Or you rarely saw it? Or even it's weird to you?

Seen it. Also seen macros, coming from Microsoft, that use this trick and distinguish between NDEBUG and _DEBUG builds.

 

[Fred Zwarts \(KVI\)]

"Qi" wrote in message news:[email protected]...

Hi all,

Let me show some code first,

void someFunction(int param)
{
(void)param; // param is not used in this function. This line is
// just to silence the compiler warning about unused param.
}

Please note the "(void)param".
Is that usage common or well known for you?
Or you rarely saw it? Or even it's weird to you?

Just your experience is enough, no need to debate for it's good
or bad.

The reason I ask this is, in my another thread, some very veteran
C++ developers said they rarely saw that kind of usage.
That makes me a little nervous because I used it a lot in my
code to *improve* the code readability.
If it's not well known trick then it reduces code readability
and then I'm going to change my code about that.

That's not only about coding style but also about code readability.

Looking forward to hearing your experience.

Thanks

I have never seen this trick. Why don't you use the standard C++ way? Remove
the name of the parameter and the compiler will stop complaining. Less code,
better readability. The "(void)param" makes me wonder what the purpose is.
You will need comments to explain why it is used. If the parameter name is
omitted, it is immediately clear that it is not used in the function. No
comments needed. For the reason why it is not used in the function, comments
may be needed in both cases.

void someFunction(int)
{

//
}

 

[Mike McCarty]

I have never seen this trick. Why don't you use the standard C++ way? Remove
the name of the parameter and the compiler will stop complaining. Less code,
better readability. The "(void)param" makes me wonder what the purpose is.
You will need comments to explain why it is used. If the parameter name is
omitted, it is immediately clear that it is not used in the function. No
comments needed. For the reason why it is not used in the function, comments
may be needed in both cases.

void someFunction(int)
{

//
}

Usually this only a problem in #ifdef'ed code. E.g.

void someFunction(int wparam)
{
#ifdef _WIN32
...
#else
// Only need this parameter on Windows.
(void)wparam;
#endif
}

This works on most compilers but the only technique that I know of that works on all compilers is this:

namespace my {
template <typename T> inline void unused(const T&) {}
}

....

my::unused(wparam);


Mike

 

[Victor Bazarov]

in message news:[email protected]...

I have never seen this trick. Why don't you use the standard C++ way?
Remove the name of the parameter and the compiler will stop complaining.
Less code, better readability. The "(void)param" makes me wonder what
the purpose is. You will need comments to explain why it is used. If the
parameter name is omitted, it is immediately clear that it is not used
in the function. No comments needed. For the reason why it is not used
in the function, comments may be needed in both cases.

void someFunction(int)
{

//
}

I've seen that trick usually used in (a) a larger function than just one
empty line and one line of comment, and (b) in presence of some reason
to keep the argument name, like alternative configurations
(Debug/Release for instance):

void someFunction(int argumentUsedOnlyInDebug)
{
... // some code
#ifdef NDEBUG
(void)argumentUsedOnlyInDebug;
#else
... // some code that uses argumentUsedOnlyInDebug
#endif
... // more code
}

Any suggestions for a better alternative?

V

 

[Qi]

I've seen that trick usually used in (a) a larger function than just one
empty line and one line of comment, and (b) in presence of some reason
to keep the argument name, like alternative configurations
(Debug/Release for instance):

I don't understand (a).
Can you give some example code?

void someFunction(int argumentUsedOnlyInDebug)
{
... // some code
#ifdef NDEBUG
(void)argumentUsedOnlyInDebug;
#else
... // some code that uses argumentUsedOnlyInDebug
#endif
... // more code
}

Any suggestions for a better alternative?

I think one more readable way is using some marco?

#define UNUSED_ARG(arg) (void)arg

UNUSED_ARG(argumentUsedOnlyInDebug);

It's less confusing than
(void)argumentUsedOnlyInDebug;

 

[Öö Tiib]

Hi all,

Let me show some code first,

void someFunction(int param)
{
    (void)param; // param is not used in this function. This line is
// just to silence the compiler warning about unused param.

}

Please note the "(void)param".
Is that usage common or well known for you?
Or you rarely saw it? Or even it's weird to you?

I have seen it. I understand what it does. Most often such functions
are still the stubs, "//TODO: implement it" and in such stage i don't
really care if and how the author silences the warnings.

A ready made function has both declaration (in header file) and
definition (in implementation file). I have seen that the declaration
contains the names even for unused parameters and definition does not
contain them. This is usually good enough in circumstances where the
reasons why the parameters are unused are obvious. For example a dummy
of unit tests:

All parameters unnamed and functions body ... something like ... throw
std::logic_error("*function_name_here* should not be called during
these tests.");. Everything is clear what and why.

Just your experience is enough, no need to debate for it's good
or bad.

The reason I ask this is, in my another thread, some very veteran
C++ developers said they rarely saw that kind of usage.
That makes me a little nervous because I used it a lot in my
code to *improve* the code readability.

May be you should discuss the cases when and why you need these unused
parameters instead?

I have feeling that something is wrong when the unused function
parameters are so frequent in a real production code of C++ project
that "a lot" can be said and special tricks are needed. The parameters
are passed with a single purpose to waste cycles so the warning feels
to be in place there. You should consider ways how to have minimum
amount of such useless parameters. That improves both readability of
your code and performance of your product.

 

[Jorgen Grahn]

Hi all,

Let me show some code first,

void someFunction(int param)
{
(void)param; // param is not used in this function. This line is
// just to silence the compiler warning about unused param.
}

Please note the "(void)param".
Is that usage common or well known for you?
Or you rarely saw it? Or even it's weird to you?

I see it a lot in C code (sometimes hidden inside a UNUSED(param)
macro). I don't think I see it in C++ code, but I don't read much of
other people's C++ code.

Just your experience is enough, no need to debate for it's good
or bad.

The reason I ask this is, in my another thread, some very veteran
C++ developers said they rarely saw that kind of usage.
That makes me a little nervous because I used it a lot in my
code to *improve* the code readability.
If it's not well known trick then it reduces code readability
and then I'm going to change my code about that.

I don't understand your reasoning. Why would the above be more
readable than

void someFunction(int) // parameter obviously unused
{}

or

void someFunction() // parameter so unused it doesn't even exist
{}

?

That's not only about coding style but also about code readability.

Looking forward to hearing your experience.

/Jorgen

 

[Victor Bazarov]

I don't understand (a).
Can you give some example code?

*You* gave the example code. In your code the function had effectively
an empty body. In that case there is no need to have "ignore"
templates, "UNUSED_PARAMETER" macros, or any other BS. Just drop the
argument altogether.

I am talking any reasonable function that actually is supposed to do
something. The "code example" is below.

I think one more readable way is using some marco?

#define UNUSED_ARG(arg) (void)arg

UNUSED_ARG(argumentUsedOnlyInDebug);

It's less confusing than
(void)argumentUsedOnlyInDebug;

<shrug> Same difference.

V

 

[MikeWhy]

Hi all,

Let me show some code first,

void someFunction(int param)
{
(void)param; // param is not used in this function. This line is
// just to silence the compiler warning about unused param.
}

Please note the "(void)param".
Is that usage common or well known for you?
Or you rarely saw it? Or even it's weird to you?

Just your experience is enough, no need to debate for it's good
or bad.

I say "NOT GOOD". It does indeed silence the compiler warning, but does not
prevent subsequent use of that param, contrary to the expectations set by
silencing the warning.

 

[Paul N]

I don't understand (a).
Can you give some example code?



I think one more readable way is using some marco?

#define UNUSED_ARG(arg) (void)arg

UNUSED_ARG(argumentUsedOnlyInDebug);

It's less confusing than
(void)argumentUsedOnlyInDebug;

I'd be wary of code that said UNUSED_ARG(arg); and then went ahead to
use arg. Perhaps POSSIBLY_UNUSED_ARG(arg); would be better in this
situation?

 

[Qi]

I say "NOT GOOD". It does indeed silence the compiler warning, but does
not prevent subsequent use of that param, contrary to the expectations
set by silencing the warning.

I did something like that.
I (void)param first, then later I added some code to use param.
Really not good and confusing...

 

[Alf P. Steinbach]

I did something like that.
I (void)param first, then later I added some code to use param.
Really not good and confusing...

Some days ago I posted the following to the thread "Any way to defer
template function overloading?":


<code>
#if !defined( CPP_DECLARE_UNUSED )
# define CPP_DECLARE_UNUSED( argName ) \
(void)(argName, void(), 0); struct argName; (void)0
#endif
// SO user sehe: "(void)0" for semicolon
// SO user R. Martinho Fernandes, pointed out operator void() problem
// SO user Johannes Schaub, solution to operator,() problem
</code>


It ensures that a param designated as unused, is not used.

It seems to me that C++ questions are sort of like memes: suddenly the
same question pops up all over the place, and then it dies out, sort of.


Cheers & hth.,

- Alf

 

[Juha Nieminen]

void someFunction(int argumentUsedOnlyInDebug)
{
... // some code
#ifdef NDEBUG
(void)argumentUsedOnlyInDebug;
#else
... // some code that uses argumentUsedOnlyInDebug
#endif
... // more code
}

Any suggestions for a better alternative?

Since the above situation is extremely rare, you could use the trick
in that specific situation (which in practice means almost never) and
add a clarifying comment to it.

Btw, do compilers by convention not issue a warning about a no-op line
like that?

 

[Juha Nieminen]

there is just one issue with this. when you use some variable only in
debug, but not in release, in the second case you still get warning. for
example:

void doSth(const char *name)
{
assert(name!=NULL);
// no other usages of 'name'
}

A compiler should be smart enough to not give a warning in the above
case even if NDEBUG is defined (because, after all, the variable *is*
used: As a parameter to a macro.)

 

[Qi]

A compiler should be smart enough to not give a warning in the above
case even if NDEBUG is defined (because, after all, the variable *is*
used: As a parameter to a macro.)

When compiler sees the code, that line has gone if NDEBUG is defined
because it's removed by preprocessor if assert is empty when NDEBUG
is defined.
So there is still warning, no?

 

[Qi]

It seems to me that C++ questions are sort of like memes: suddenly the
same question pops up all over the place, and then it dies out, sort of.

Not really. My other thread is about template function overloading.
This thread is the only one I started about unused parameter.

 

[Jorgen Grahn]

Since the above situation is extremely rare, you could use the trick
in that specific situation (which in practice means almost never) and
add a clarifying comment to it.

Unfortunately, such code is not rare everywhere. Bad high-level design
choices ("feature A and B have similarities; let's call them FOO and
implement them with the same code. Only a few ifdefs needed ...") plus
a ban on compiler warnings leads to such things.

Btw, do compilers by convention not issue a warning about a no-op line
like that?

Yes, that's my impression. I wouldn't be surprised if it was lint that
introduced the convention in the 1980s or earlier.

/Jorgen

 

[Juha Nieminen]

When compiler sees the code, that line has gone if NDEBUG is defined
because it's removed by preprocessor if assert is empty when NDEBUG
is defined.
So there is still warning, no?

In the era where the C preprocessor, the compiler and the linker were
all completely separate programs that might have been the case (because
the compiler, which is the one issuing warnings, does not see the original
source code, only the code generated by the C preprocessor).

However, in modern compilers there really is no need to separate the
C preprocessor from the compiler so at least in principle the compiler
could see that "hey, this variable is given as parameter to this macro"
and thus elide the warning.

OTOH, I don't know if any modern compiler is that smart... I'm just
talking hypothetically here.

 

[Juha Nieminen]

Unfortunately, such code is not rare everywhere. Bad high-level design
choices ("feature A and B have similarities; let's call them FOO and
implement them with the same code. Only a few ifdefs needed ...") plus
a ban on compiler warnings leads to such things.

Reminds me of an open source project (which shall remain unnamed)
where the developers had the breaindead principle that, 1) all warnings
are errors (by using the gcc flag for that), and 2) they used every single
warning flag that they could find on gcc's info page. Naturally they
considered these settings mandatory for official builds.

This meant, for example, that if gcc did not inline a function that
was marked as 'inline' you would get an error, even though that situation
is completely inconsequential to the validity of the program. (The warning
in question is purely informative, and not turned on with -Wall, for
obvious reasons.)

It also meant that the program might compile with one version of gcc but
not with another, if they use different inlining strategies. Way to go.