# Visual C++ 2008 - compiler changing function names?

## Recommended Posts

YellowMaple    174
Hello, I'm trying to build a project in VC++ 2008. However, I get the following error: StaticMeshComponent.cpp h:\code\parallax\src\staticmeshcomponent.cpp(4) : error C2039: 'GetClassNameA' : is not a member of 'StaticMeshComponent' Which refers to this line of code [in StaticMeshComponent.cpp]:
[source lang="cpp]
#include "RenderComponents.h"
#include "SDL_opengl.h"

DEFINE_COBJECT_BASE_CLASS(StaticMeshComponent);  // Problem :(
...


where DEFINE_COBJECT_BASE_CLASS is #defined in "CObject.h" [StaticMeshComponent derives from CObject] as shown:
#define DEFINE_COBJECT_BASE_CLASS(_Class_)							RTTI* _Class_::s_RTTI = new RTTI( #_Class_ , 0 );				CObject* _Class_::Clone()										{																	return new _Class_(*this);									}																CObject* _Class_::NewObject()									{																	return new _Class_();										}																const RTTI* const _Class_::GetType()							{																	return s_RTTI;												}																const ClassName& _Class_::GetClassName() const					{																	return s_RTTI->TypeName;									}																bool _Class_::IsA(const RTTI* pRTTI) const						{																	RTTI *pCurRTTI = s_RTTI;										while( pCurRTTI )												{																	if( pRTTI == pCurRTTI )												return true;												else																pCurRTTI = pCurRTTI->pParent;							}																check_msg(0, "Should not be here for RTTI check");				return false;												}


I don't understand why the compiler is appending the letter 'A' to the function name (i.e. GetClassNameA) when in the directive, it clearly is spelled properly. StaticMeshComponent derives from IRenderComponent (which only has a virtual function: virtual void Render() = 0;) which derives from IComponent (which has 3 pure virtual functions, void Initialize(), void Update(float fTimeDelta), and void Destroy()). I'm using SDL for the project as well. Any ideas? thank you in advance.

##### Share on other sites
Dave Hunt    4872
That's caused by the stupid windows headers. All windows functions that might need different behavior in a non-Unicode vs Unicode environment have two flavors, one with an A appended and one with a W appended. The windows headers have macros that redefine the function depending on your project settings.

If you create a function with the same name as one of those windows functions, those macros will blindly muck up your functions as well.

The simple fix in your case would probably be to reverse the order of the includes so that the windows headers get included first. That will muck up your function declarations so that they match the mucked up function calls.

Or, avoid having function names that clash with windows functions.

edit - fixed a speeling mistake. what's a "flaver" anyway?

[Edited by - Dave Hunt on April 22, 2008 3:53:45 PM]

##### Share on other sites
YellowMaple    174
Thank you for the quick reply! I think I'll just end up changing the name.

##### Share on other sites
Bregma    9214
Might I also suggest that if you use symbol names "reserved to the implementation" (such as a symbol containing an underscore character followed by an upper case letter) you are Inviting Trouble. Any resulting problems will be Your Responsibility.

--smw

##### Share on other sites
osmanb    2082
While that may be true, Bregma, it has nothing to do with the OP's problem. This is a well-known and documented disaster resulting from incredibly sloppy crap in windows.h. Some of the functions that get mangled like this have really common names, too. I think 'PlaySound' is my favorite.

##### Share on other sites
jpetrie    13162
Quote:
 While that may be true, Bregma, it has nothing to do with the OP's problem.

No, but the OP's problem was addressed already, and what Bregma points out is a valid and related concern.

The name collision issue with the Windows headers is unfortunate, I agree, but I don't think you're fully appreciating the compatability constrains that header and its dependencies need to operate under.

Besides, it's trivial to avoid 95% of the name collisions by appropriately scoping the include of the file (I've only ever included it three or four times in any of my C++ projects, for example). You get a fairly large compile-time performance increase out of this too if the header was previously pathologically included everywhere.

Unfortunately, this is harder to do in OpenGL projects because of the intimate dependency between the GL headers and the Windows header in terms of include order.

## Create an account

Register a new account