Article ID: 155046
Article Last Modified on 6/2/2005
APPLIES TO
- Microsoft Visual C++ 4.0 Standard Edition
- Microsoft Visual C++ 4.1 Subscription
- Microsoft Visual C++ 4.2 Enterprise Edition
- Microsoft Visual C++ 5.0 Enterprise Edition
- Microsoft Visual C++ 6.0 Enterprise Edition
- Microsoft Visual C++ 4.2 Professional Edition
- Microsoft Visual C++ 5.0 Professional Edition
- Microsoft Visual C++ 6.0 Professional Edition
- Microsoft Visual C++ 6.0 Standard Edition
This article was previously published under Q155046
SYMPTOMS
Leaving the parentheses off a member function call, or leaving the ampersand (&) off a reference to a pointer to a member function, does not result in a compiler error.
CAUSE
In both cases, the Visual C++ compiler is incorrectly treating the reference as a pointer to the member function. A pointer to a member function cannot be referenced via a specific instance of a class (for example, "obj.MyFunct" in the sample code below). Instead, it must be referenced via the class name, scope operator and '&' operator (for example, &CMyClass::MyFunc in the sample code below).
RESOLUTION
The compiler should report an error on the line in question.
STATUS
Microsoft has confirmed this to be a bug in the Microsoft products listed at the beginning of this article.
This problem was corrected in Microsoft Visual C++ .NET.
MORE INFORMATION
Sample Code
/* Compile options needed:
*/
class CMyClass
{
public:
void MyFunc() {int nVar = 100; }
};
void main()
{
CMyClass obj;
obj.MyFunc(); //Correct syntax - calls the member function
obj.MyFunc; //Typo, no (), should result in error but doesn't
//VC 5.0: correct warning C4551
CMyClass::MyFunc; // Typo, no &, should result in error but doesn't
&CMyClass::MyFunc; // Correctly treated as a pointer to member
// function.
}
Note that executing the program generated by the above code causes no run- time errors, but executes MyFunc only once. The incorrect line has no affect because it is treated exactly the same as the line following it.
Also note that this problem could seem to cause incorrect execution paths if the parenthesis are left off accidentally in the following type of construct:
if (obj.MyFunc) { // Should be an error, instead always evaluates to
// TRUE. This code always executes.
}
else {
// This code will never be reached.
}
Additional query words: kbVC420bug kbVC400bug
Keywords: kbbug kbnoupdate kbcodegen kbcpponly kbcompiler kbfunctions KB155046
