C++ Linking error within projects having different character set

Question

I am having linking error while compiling my C++ project Solution in VS 2005. Following is the scenario.

I have a solutions lets say MySolution within which there are 2 projects named

MyTestLib is a Static Library type project with Character Set Use Multi-Byte Character Set and with no CLR support

and

MyTestApp is a .exe app using the above lib with Character Set Use Unicode Character Set and with CLR support

in MyTestLib there are two overloaded functions with following definitions

int Class1::test1(int a)
{
    return a+4; 
}

bool Class1::test1(LPCTSTR param)
{
    return true;
}

MyTestApp is calling them from its code like

Class1 objcl1;
int a = objcl1.test1(12); //Works fine

Class1 objcl2;
string abc = "adsad";
bool t = objcl2.test1(abc.c_str()); //Error

calling the test1(LPCTSTR) version gives error

Error 1 error C2664: 'int TestLib::Class1::test1(int)' : cannot convert parameter 1 from 'const char *' to 'int'

if I change the statement as bool t = objcl2.test1((LPCTSTR)abc.c_str()); //Now linking Error bool t = objcl2.test1((LPCTSTR)abc.c_str()); //Now linking Error Then I get

Error 2 error LNK2001: unresolved external symbol "public: bool __thiscall TestLib::Class1::test1(wchar_t const *)" (?test1@Class1@TestLib@@$$FQAE_NPB_W@Z) TestProject.obj

but if I change the project MyTestApp Character Set to Use Multi-Byte Character Set then all the errors are resolved. But I can't change the project Character Set, as there are other dependencies.

Is there any work arround?

Answer 1

The problem is that when you build MyTestLib this signature:

bool Class1::test1(LPCTSTR param);

Becomes

bool Class1::test1(const char * param);

Because LPCTSTR is a macro that is set depending on the "Character Set" configuration in place when the build occurs.

Now, when you build MyTestApp with the "Character Set" configured for UNICODE, it sees that function signature (from a header file, I assume) as:

bool Class1::test1(wchar_t const * param);

So the linker has no hope of linking that function to what's actually in the library.

The workaround is to simply not use LPTCSTR as the type for the function - the type of that parameter in the implemented function will always be const char* , so just say so in the function declaration.