Usage of pre-processor macro.

[Guru]

I have seen this below code snippet.But i dont know how to explain
this.
Can any one help me out, what exactely is happening here.


#define UNREF_PARAM(Param) \
{ \
(Param) = (Param); \
}

int BaseClass::func(pointer *ptr)
{
UNREF_PARAM(ptr);
return success;
}

 

[Helge Kruse]

I have seen this below code snippet.But i dont know how to explain
this.
Can any one help me out, what exactely is happening here.


#define UNREF_PARAM(Param) \
{ \
(Param) = (Param); \
}

int BaseClass::func(pointer *ptr)
{
UNREF_PARAM(ptr);
return success;
}

This makes the compiler happy. If you omit the UNREF_PARAM, the compiler may
warn about unreferenced parameter(s). The macro creates code where the
parameter is assigned to itself. This doesn't hurt and is optimized away if
optimization is enabled.

You could also write following to avoid the compiler warning:

int BaseClass::func(pointer*)
{
return success;
}


Helge

 

[Ian Collins]

This makes the compiler happy. If you omit the UNREF_PARAM, the compiler may
warn about unreferenced parameter(s). The macro creates code where the
parameter is assigned to itself. This doesn't hurt and is optimized away if
optimization is enabled.

You could also write following to avoid the compiler warning:

int BaseClass::func(pointer*)
{
return success;
}

The macro is probably intended for C code rather than C++.

 

[Guru]

This makes the compiler happy. If you omit the UNREF_PARAM, the compiler may
warn about unreferenced parameter(s). The macro creates code where the
parameter is assigned to itself. This doesn't hurt and is optimized away if
optimization is enabled.

You could also write following to avoid the compiler warning:

int BaseClass::func(pointer*)
{
  return success;

}

Helge

Thanks Helge Kruse.

 

[cpp4ever]

Pete Becker ha scritto:


I often see this warning labelled as "stupid", but have you never had a
situation in which, by accident, you really were using the wrong
variable in the function? Something along the lines of:

int MyClass::calculate(int x, int y)
{
return complicatedCalculation(x, x); // bug, should be x, y
}

Are some "false positives" of this warning a reason to give away a
chance to automatically detect such bugs?

Agreed! That's why I now rarely use macro function definitions,
preferring to use templates.

regards

cpp4ever

 

[Öö Tiib]

I have seen this below code snippet.But i dont know how to explain
this.
Can any one help me out, what exactely is happening here.

#define UNREF_PARAM(Param) \
{ \
    (Param) = (Param); \

}

int BaseClass::func(pointer *ptr)
{
  UNREF_PARAM(ptr);
  return success;

}

Like others told it is for suppressing warnings.

Alf P. Steinbach has relatively useful blog about suppressing warnings
on microsoft compilers somewhere in his http://alfps.wordpress.com/
He did use template for same reason (what i think is better idea):

template< typename T >
inline void suppressUnusedWarning( T const& ) {}

His template works on cases when your macro does not work:

class BaseClass
{
virtual int func_2(float const& ref)
{
// uncomment next line for compiler error
// UNREF_PARAM( ref );
suppressUnusedWarning( ref ); // OK
return 0;
}
};

Suppressing that warning (about parameter not being used) may be valid
with virtual member function override that happens to not need all the
parameters. In other functions it is likely real bug (something
unimplemented or typo made). Do not turn that warning off if your
compiler warns about it.

 

[Öö Tiib]

Yes. If you've written good unit tests, ignoring a function argument
that matters will always be detected.

Unit tests do not usually test design problems, so how they help?

Parameters that do not matter are usually present because of a design
problem. Problem is that virtual function does not manage too well
with its two responsibilities:
1) to allow polymorphism.
2) to be convenient interface.

When that problem is acknowledged (and decision is made to ignore it)
then it is OK to suppress that warning at that place. When such design
(pointless parameters) is forced upon developer by overly intrusive
library it might be annoying, yes. I would consider giving a good kick
to such library instead of turning off the warning globally, however.

 

[Öö Tiib]

They help because *using the wrong name variable* (emphasis added) is
not a design problem, but a coding problem.

There they detect same coding problem as that warning in different
ways. Lets say someone does code there something and makes such a
coding error. Will he repair it more quickly if he see both
diagnostics or only one of them? IOW i do not still get why you
suggest to silence it globally.

 

[Öö Tiib]

Because not using a function parameter is a legitimate coding
technique, and having to sort through warnings about it to figure out
whether there's a genuine error, or adding extraneous code in order to
suppress bogus warnings, is a distraction.

Leaving parameter that is not going to be used without name is
legitimate technique in C++ how to mark such a parameter in most
laconic way (without adding extraneous code).

Let me describe again the situation when the warning is bogus:
1) Functions signature contains a parameter with what there are
nothing to do in function body.
2) There is reason why to ignore that design problem of virtual
function not managing to do its both tasks well.
3) The bogus parameter still has name for some reason (like other
compiler for other platform that complains when it has no name).

Is it really so "extraneous" to mark that place somehow that it is
exactly as it is supposed to be? I would expect "why?" comment as
well.

But perhaps I assume too
high a degree of professionalism in programmers; if you feel that you
can't write adequate unit tests, or won't run them, then perhaps you
need more help in identifying a low-probability error, and sorting
through the extra noise is worthwhile for you.

Where did you get such nonsense from what i have said? Professionalism
can be enforced by process. Unit tests should be additionally ran by
separate systems. At least one per platform what is supported. These
should automatically run all the tests each time someone pushes
something into main repository of product. So if a developer did not
run the tests on code he broke and the reviewer who pushed it into
main repository also did not notice then whole team will hear about
it.

All i said was that when people have everything: (a) unit tests
failure, (b) repository changeset that caused it and (c) diagnostics
from tools/compilers it will be fixed most quickly. Average programmer
wastes most of his time by dealing unproductively with such "low-
probability errors". Where to take star-programmers who understand
everything on fly? Nowhere. It is lot easier to arrange average joe to
behave professionally. And ... it is good idea to squeeze everything
what is possible out of tools.

 

[Ian Collins]

Even more to the point is that this is utterly trivial. If I meant to
not use a parameter, time spent telling the compiler that that's what I
meant is simply wasted. If I should have used it, unit tests will detect
the error. And this is such a low-probability error that any time spent
analysing how to deal with it is too much time. It's far up on my list
of things to not worry about.

While all true, simply not naming the parameter make the argument moot.

 

[Fred Zwarts]

Yes. If you've written good unit tests, ignoring a function argument
that matters will always be detected.

Yes, but it takes a lot more time to build and run all the unit tests.
An early warning at compilation time may increase the productivity.

 

[Fred Zwarts]

Because not using a function parameter is a legitimate coding
technique,

I wonder why something that is not used is given a name.
Why is that a legitimate coding technique?
It only increases the "entropy" of a program,
just like declarations of unused variables.

and having to sort through warnings about it to figure out
whether there's a genuine error, or adding extraneous code in order to
suppress bogus warnings, is a distraction. But perhaps I assume too
high a degree of professionalism in programmers; if you feel that you
can't write adequate unit tests, or won't run them, then perhaps you
need more help in identifying a low-probability error, and sorting
through the extra noise is worthwhile for you.

Units test are useful, but there is a reason why compilers also produce diagnostics.
A professional programmer knows to use compiler diagnistics in addition to unit tests.

 

[P. Lepin]

I wonder why something that is not used is given a name.
Why is that a legitimate coding technique?
It only increases the "entropy" of a program,
just like declarations of unused variables.

Epistemologically speaking, it can be immensely useful to clearly indicate
that foo() conforms to a requirement of defining something through bar and
baz, but this particular implementation is actually independent of baz.
Assuming meaningful function and parameter names, this can be slightly more
enlightening that saying that foo is passed a const std::vector<T>& but
doesn't care about it in the least.

This is just my own opinion, though.

 

[P. Lepin]

Good commentary explains much more than the names of variables and
parameters can do.

Oh, if you prefer absolute statements, here's one for your enjoyment:

Good code doesn't need commentary.

 

[James Kanze]

Unit tests do not usually test design problems, so how they help?

Because the example error wasn't a design problem, but a typo.

Parameters that do not matter are usually present because of a design
problem. Problem is that virtual function does not manage too well
with its two responsibilities:
1) to allow polymorphism.
2) to be convenient interface.

When that problem is acknowledged (and decision is made to
ignore it) then it is OK to suppress that warning at that
place.

A better solution would be to not name the parameter in the
functions which don't need it.

 

[James Kanze]

On 2010-06-30 17:03:20 -0400, Pete Becker said:

Even more to the point is that this is utterly trivial. If I
meant to not use a parameter, time spent telling the compiler
that that's what I meant is simply wasted.

Even the time spent giving it a name in the first place is
wasted. And if you don't give it a name, you shouldn't get the
warning. However...

If I should have used it, unit tests will detect the error.

More importantly: in my experience, inverting the parameters (in
this case) is a far more frequent error. Which the warning
won't detect, but even the most trivial unit test should. The
warning is worthless, but because you don't have to give the
parameter a name (and not giving it a name is the consacrated
way of saying that you don't use it), it's generally not worth
the bother of turning it off. (For parameters. I did use a
compiler in the past that warned about local variables not being
used, even if they had a non-trivial destructor. In other
words, most uses of RAII would trigger a warning.)