unusual implementation signature

If the in the class definition you have:

bool endElement( const QString & namespaceURI,const QString & localName, const QString & qName );

and you implement the method thus:

bool MyHandler::endElement( const QString&,const QString& ,const QString& ) {
blah;
blah;
blah;
}

I don't understand why the compiler accepts this ommition of parameter names. Even worse if you try to use one of the parameter names(like qName) inside this method implementation, you get a 'symbol not defined error' . However if one replaces the above implementaton with the following one, one gets to use the parameters without any errors:

bool MyHandler:: endElement(( const QString & namespaceURI,const QString & localName, const QString & qName ) {
blah;
blah;
blah;
}

Can anyone explain to me what is at play here?

Beats me. But here is an idea...don't do it then. It seems to me your asking a question for the sake of asking, the answer will not bring value or not any you can use now. I know that u can omit parameter names in the class definitions, then place parameter names in the implementation to make your definition shorter. Chances are good it has something to do with that. The other way around has no apparent use.

All I did was check the parameter name I wanted to use from the main definition, and defined it in the code file. I think it's just to hide unused overloaded arguments really, maybe for clarity?

@Marthinus you are missing the point buddy. If one encounters something that seems bizarre,logically, one should wonder why the compiler does not reject it, regardless of whether you know how to get around it or not. I just thought I should ask in case its a feature of C++ (or even Qt) that has benefits I am not unaware of.

Qt is not a language, it is a framework. It has to obey all of the syntax and grammar rules of the language its implemented in. In this case, it's obeying c++. All the new keywords (eg slots, SIGNAL, etc) and the program constructs (eg foreach, forever, etc.) are merely illusions and are actually implemented via ordinary c++ precompiler macros. moc, uic and rcc are extra programs that generate extra code to help with the framework. They are ordinary c++ files and get compiled and linked into your programs just like your own creations. You could write them yourself if you knew what needed to be done.

-------------------------

The signature of a function requires the function name, the number and types (including const'ness) of the parameters, and, if a class method, whether it's virtual and/or const. That is all that is necessary to uniquely identify a function header with a function body. The parameter names and the return type are not part of the signature.

For this reason, you do not need to supply parameter names. As you've found out, you will not be able to use any of the data passed into a function by a parameter unless you have a name. Note that the parameter name stated in the function declaration is ignored completely by the compiler. The only one that's important is the name in the function definition. A consequence is that you can use different names in your declaration and your definition and all will work as expected. The only thing that matters is the position and type of the parameter.

My understanding of the reasoning behind this is because the parameter names are only meaningful to the programmer. All the compiler needs to know is the position and type. Thus, it's wasteful to store and track a symbol that's redundant. If you've noticed, you'll never see a parameter name in any error messages, only the type. This is because the compiler doesn't care about the name. It only becomes important if you actually use the name in the body of the function, which is not always the case.

There are some instances of library creators that will create base classes that you can derive your own specialised classes from. The original creator will sometimes provide virtual functions that produce a default behaviour that you may or may not choose to override. These default functions quite often don't need to use all or any of the parameters so the creator will usually not give them names.

eg.

Language: C++
class DatabaseTable {
public:
   DatabaseTable() {}
   virtual void updateRecord(int row);
};
 
void DatabaseTable::updateRecord(int){
   // default implimentation does nothing
}
 
class EmployeeTable : public DatabaseTable {
public:
   EmployeeTable() : DatabaseTable() {}
   virtual void updateRecord(int row);
};
 
void EmployeeTable::updateRecord(int row){
   // does something with the row variable
}

Also note, that because the compiler doesn't care what the parameter names, you are perfectly allowed to use different names in the declaration to that of the definition. If you use a name in the declaration, as you have done above, it does not mean that it is known in the definition.

Language: C++
class MyHandler {
////
   bool endElement( const QString & namespaceURI,const QString & localName, const QString & qName );
////
};
 
bool MyHandler::endElement( const QString&,const QString& ,const QString& ) {
   //blah;
   //blah;
   //blah;
}

Note that the class definition is merely there to let the compiler know about the structure of the class. It does not link through to the definition of each function. That is the job of the linker, not the compiler. When you create each function definition, and you choose to use one of the parameters, you must have the name in the definition's parameter list.

This would be a better choice if you wished to omit parameter names:

Language: C++
class MyHandler {
////
   bool endElement( const QString&,const QString& ,const QString& );
////
};
 
bool MyHandler::endElement( const QString & namespaceURI,const QString & localName, const QString & qName ) {
   //blah;
   //blah;
   //blah;
}

In my opinion, you should always provide parameter names in your declarations so that users of the class can know what each parameter is for. They usually don't get to see the implimentation of the functions so you can omit the names there if you don't need to use them.

@Rob: Yeah I'm with on the parameter name inclusion, and thanks or explaining it comprehensively.
@J: Sorry, didn't mean you shouldn't ask questions man. Just looking out of my own perspective. If something isn't really a problem, rather spend time on things that are. To me programming is need to know. Cause there is endless amount of things to know, but little that is relevant to a situation. But what you do, is all up to you. Even tried to help with some insight . Peace!

thanks Rob, it all makes sense.
@Marthinus, no harm done

The anonymous parameters are useful when you want to override methods from a super class and you don't need to use all of the parameters.
e.g. if you are only using localName, and are not interested in the namespace or qualified name, your function definition could be as follows:
bool endElement( const QString&, const QString& localName, const QString& );

This method signature matches the definition correctly for purposes of overriding, but does not introduce unused variable names.