Sometimes I see code like this:
LRESULT OnPaint(UINT /*uMsg*/, WPARAM /*wParam*/, LPARAM /*lParam*/, BOOL& /*bHandled*/)
Why comment pa
Some compilers wouldn't issue a "unused argument warning" when you comment the argument or not provide it in the first place. But of course you would need to leave the type to have the correct signature.
If the called function (OnPaint
in your example) do not use the arguments, the coder can avoid warning messages about unused arguments when compiling by not providing argument names.
I think there are/were some compilers which issued a 'argument not used' warning when, well, the arguments were not used.
Especially in message handler functions like the one you showed, the arguments are often not necessary to perform the task. So by commenting the argument names out, you could get rid of the warnings.
On the other hand, if you later want to use some of the arguments, it's useful to have the names at hand, so commenting out is easier than just deleting the names.
If that is the beginning of the definition of onPaint()
I have seen commented out argument names used to avoid "unreferenced formal parameter"
compiler warnings (these warnings will only appear at a high warning level, level -W4
for Microsoft compilers).
One reason I see for doing this is that you explicitly want to tell other programmers not to use the parameters, but leave them in comments for a description of their intent. I know this doesn't make sense now, but read on.
I'll use a different example:
class A
{
public:
virtual void foo(int someProperty);
};
class B : public A
{
public:
virtual void foo(int /*someProperty*/);
};
Say you want this for a specific case where you want B::foo()
to do some extra stuff, and then call A::foo()
with the parameter 0
. You have to keep the same function signature, so polymorphism works, but, inside B::foo()
, you're not actually using the parameter. Nor do you want to use it in the future. It's basically a statement of intent, saying "the logic of this method should not depend on someProperty".
B::foo(int/*someProperty*/)
{
//do some stuff
A::foo(0);
}
With the parameter name commented out, you can't really use it (unless you get down to some hacking). But the commented name tells you something about the parameter you pass to A::foo()
- its 'someProperty' from A
.
Now, I don't agree with the syntax, but this can be a possible explanation.
If the parameters are really not needed, you don't need to name them
If you don't name them, at first glance you may not understand why they are there in the first place.
If you name them, some compilers will you warn you about unused parameters.
Leaving the names as comments is a middle ground between the two approaches.