A customer was encountering an unresolved external linker error when trying to link a plug-in with a static library.<\/p>\n
\/\/ header.h\r\n#define UNICODE\r\n#define _UNICODE<\/a>\r\n#include <windows.h>\r\n\r\nBOOL SetSessionName(LPCTSTR name);\r\n<\/pre>\nThis header file is used both by the implementation:<\/p>\n
\/\/ implementation.cpp\r\n#include \"pch.h\"\r\n#include <header.h>\r\n\r\nBOOL SetSessionName(LPCTSTR name)\r\n{\r\n \/* ... *\/\r\n}\r\n<\/pre>\nAnd it is used by the plug-in:<\/p>\n
\/\/ plugin.cpp\r\n#include \"pch.h\"\r\n#include <header.h>\r\n\r\nvoid Initialize()\r\n{\r\n SetSessionName(TEXT(\"Fred\"));\r\n}\r\n<\/pre>\nThe result when building the plug-in is an unresolved external:<\/p>\n
LNK2019 unresolved external \"int __cdecl SetSessionName(char const*)\" (?SetSessionName@@YAHPBD@Z)\r\n<\/pre>\nWhat’s going on? The header file sets Unicode as the default before including the
windows.h<\/code> header file, so everything should be Unicode, shouldn’t it?<\/p>\nLet’s look at what the error message is telling us. It says that the plug-in wants a function that takes a
char const*<\/code>, which is whatLPCTSTR<\/code> maps to when ANSI is the default. So somehow the Unicode setting isn’t sticking when the plug-in is using it.<\/p>\nI usd my psychic powers to guess that the plug-in had already performed its own
#include <windows.h><\/code> before includingheader.h<\/code>, and that initial inclusion ofwindows.h<\/code> was done with ANSI as the default character set. Theheader.h<\/code> is changing the character set too late.<\/p>\nOkay, so now that we understand the problem, how do we solve it?<\/p>\n
One option is to give up on ANSI. Just be all-Unicode all the time. After all, any plug-in that is ANSI-based is going to have problems with file names, user names, all sorts of things.<\/p>\n
But the customer said that they wanted to support both ANSI and Unicode plug-ins. Mind you, I’m not sure I believe that, seeing as their header file tried to
#define UNICODE<\/code> to force Unicode, but I’m going to take them at their word. Maybe the#define UNICODE<\/code> was just an experiment.<\/p>\nIf you want to support either character set, then you need to define two versions, one for each character set. (While you’re at it, specify a calling convention already.) Classic Win32 uses C-style bindings, so you would have to decorate the function names manually:<\/p>\n
EXTERN_C BOOL WINAPI SetSessionNameA(LPCSTR name);\r\nEXTERN_C BOOL WINAPI SetSessionNameW(LPCWSTR name);\r\n<\/pre>\nYour implementation file would have to implement both the A and W<\/a> versions.<\/p>\n
Another option is to use C++ decoration and overloads.<\/p>\n
BOOL WINAPI SetSessionName(LPCSTR name);\r\nBOOL WINAPI SetSessionName(LPCWSTR name);\r\n<\/pre>\nThe downside of this is that it requires the plug-in to use the same compiler that your framework is written in. This is generally not a great idea, since your customers will probably have a preferred toolchain, and forcing them to use a specific compiler (and perhaps even a specific version of a specific compiler) will make it harder for you to make friends.<\/p>\n
Even worse: If your toolchain is the Microsoft Visual C compiler, then you have to deal with the \/Zc:wchar_t<\/tt> option, which means bringing
__wchar_t<\/code> into the picture<\/a>.<\/p>\nBOOL WINAPI SetSessionName(LPCSTR name);\r\nBOOL WINAPI SetSessionName(unsigned short const* name);\r\nBOOL WINAPI SetSessionName(__wchar_t const* name);\r\n<\/pre>\n