The question is in reference to this, which was posted a little while earlier.
While the OP was happy accepting the answer which solved his problem I was a little intrigued with a detail as to why compiler gave a seemingly wrong error.
Below is a small code sample I created to demonstrate the same:
class YourClass
{
};
class YourClass2
{
};
class MyClass
{
public:
void doSomething(YourClass2 obj)
{
//Nothing more Interesting to do
}
};
int main()
{
YourClass *ptr = new YourClass();
MyClass obj;
obj.doSomething(ptr);
return 0;
}
Compiling this with GCC(4.3.4) gives a seemingly strange error result:
prog.cpp: In function ‘int main()’:
prog.cpp:23: error: no matching function for call to ‘MyClass::doSomething(YourClass*&)’
prog.cpp:13: note: candidates are: void MyClass::doSomething(YourClass2)
So the Question is:
Why does the compiler treat the call,
obj.doSomething(ptr);
as call to a function with prototype,
MyClass::doSomething(YourClass*&)
and not
MyClass::doSomething(YourClass*)
which seems to be the obvious case.
As others have stated, the compiler is trying to be helpful, and probably confusing you. Lets start with the simplest error:
While the error message is correct, the information that it provides is very limited. In this example the code is simple to follow, but consider a more complex piece of code. You read the error message and you may think… what’s obj?, what’s ptr? So it tries to help you and tells you what
objis:Well, that’s better, it is telling you at least in what class you need to look for the overload, but consider that the class was
std::ostreamand the functionoperator<<… there are just too many overloads, and still, what is the type ofptr? So it moves forward and tries to describe the argument: The argument is an lvalue of typeYourClass*… and I have seen that type of error message produced in the past:Ok, so the error report is complete. Now think that the function might have more arguments, and the error message can turn into a complex beast (imagine a list of 5 “rvalue of type XXX and an lvalue of type YYY and …”). The next thing is making the syntax of the error message just as precise (the lvalue-ness of the argument is important, or the rvalue-ness would be important, so that piece of information has to be present). So it rewrites the error message again:
The problem is that you are trying to interpret that as a function signature, but it is rather the description of the function call.
Error messages are not defined in the standard, and they differ from one compiler to another, even from one version to another within the same compiler. At the end of the day you need to learn to read the error messages and what they mean.