C++ : What does a commented arrgument mean?

[Dihi Doctor]

I am quite new to c++ and since starting have noticed on a few occasions functions with arguments identifiers apparently "commented out". I haven't had any real problems, but I was wondering if it meant anything in particular.

For example, in a function to repaint an object from an example in the QT toolkit (this function is an overridden protected from its parent class).

 void paintEvent(QPaintEvent * /* event */)
{
....
}

Why is it not?:

 void paintEvent(QPaintEvent *  event)
{
....
}

So, is there any relevance of "/*event */" rather than just "event" here?

[Dougal]

The event section has been commented out the compiler ignores it

void paintEvent(QPaintEven *)
{
...
}

Is the actual function, the "event" is just to tell you its an event.

All the function is doing is obtaining a pointer to a QPaintEvent.

But it should have a name according to what I have been taught.

[TheAnimus]

i think it might well be just a typo, i've not really done that much ++ but i've never seen something like that, nor can i understand what it would mean, the first * is for indirection, but it should then have an identifier. By encapsulating the identifyer in comments, it wouldn't get parsard, and it would find the end bracked, and should throw a build error.

[Dihi Doctor]

Ah, I see. I think it strange, like Dougal, that the argument has no identifier, but I suppose it doesn't need one if it's not referenced (it only needs an argument to fit the function prototype of the inherited function).
I would have included an identifier, if I was writing this, so as not to confuse people like this has confused me.
Thanks for the speediness in responding

[GizmoStu]

That's a rather unusual coding convention! Still, each to their own eh?

I personally find commenting arguments to be useful when dealing with default values (i.e. the default value is commented in the implementation). Can save some headscratching.

[Dougal]

I still think its wrong.

That pointer has no name to be used within the function therefore there is no way it can be referenced.

So in effect it should bring up a warning at the very least.

[Paul Adams]

I don't think it throws out a compiler or linker error, it's not good practice but the labels are only for the programmer's benefit.
Arguments passed to functions can be referenced if you use a pointer to the stack, so it's not necessary to use labels.

[Dougal]

That;ll be why then, we just covered stack theory and how it worked.

[Paul Adams]

I remember seeing some very odd-looking code in assembler years ago, when every CPU cycle counted for writing graphical "demos" for MCGA displays... a call to a subroutine would push arguments onto the stack, but the subroutine would actually point directly to the stack to use them, not pop them off, then it would manually move the stack pointer in 1 CPU operation instead of 1 per stack pop.

Cunning, and ultimately unreadable code

[Dihi Doctor]

Cunning, and ultimately unreadable code

Ah a classic professional practice unless I am very much mistaken

[Paul Adams]

Ah a classic professional practice unless I am very much mistaken

Most likely
A friend of mine inherited some source code along with a big project he was handed, and the original programmer had used variable names such as "a", "aa", "aaa", "ooooh", "hmmm", "b1", "b2" and so on.... most of which were never actually used for anything.

I could never program for a career, other people's (lack of) coding standards would drive me insane!

[GizmoStu]

Some people have no concept of teamwork! I'm glad to work in an environment where good coding standards exist. New people on the team usually have trouble adopting them, but I find that our coding standards certainly makes the code more readable when it needs to be (i.e. when it's 7pm on a Friday and a client needs something doing "now").

[Dougal]

Opensource goddamnit!

[Butcher]

It's not a syntax error to have an unnamed argument to a function in C++

void foo (int)
{
// do stuff
}

is valid, though you can't actually use the int passed.

NB, directly fiddling the stack is very bad practice in C/C++. Not naming your arguments so you can hack the stack is not a good idea. The compiler will read them straight off the stack rather than popping them in any event.

[TheAnimus]

i would of hope it at least gives a warning?

if its stdcall, the calling code will push and pop that one param, as its upto the calling program to balance. So i would of thought hacking the stack like that (thou i can't see why you'd want to) would work.

[Butcher]

It doesn't give a warning; it's perfectly legal code.
You can't use the param, but it still gets passed. It's normally used for virtual functions where the specific implementation doesn't need the param but it needs to be there for overload resolution. Or in callback functions where the function has to comform to a specific prototype, but the code doesn't use the param. It's also sometimes used for backwards or forwards compatibility.

For reference the standard explcitily states that parameters need not be named:

An identifier can optionally be provided as a parameter name; if present in a function definition (8.4), it names a parameter (sometimes called “formal argument”). [Note: in particular, parameter names are also optional in function definitions and names used for a parameter in different declarations and the definition of a function need not be the same. ... ]