链接 lib 时未解析的外部符号，编译器将字母“A”添加到函数名称

Question

尝试链接 win32 exe 项目时出现此错误。我已链接到包含此方法的代码的库。但仍然出现未解决的符号错误。

error LNK2001: unresolved external symbol "public: bool __thiscall SharedJobQueue::AddJobA(class boost::shared_ptr<class domain::Job>)" (?AddJobA@SharedJobQueue@@QAE_NV?$shared_ptr@VJob@domain@@@boost@@@Z)

为什么显示为 AddJobA，末尾带有 'A'。该方法被声明为 AddJob。

我查看了 'dumpbin /symbols' 的输出，它只包含 AddJob 的符号，而不包含 AddJobA 的符号。为什么编译器要在函数名末尾添加“A”？

Answer 1

MS 使用 Win32 API 的宏来通过在函数名称后添加

A

或

W

后缀来支持 Unicode 和 Ansi 构建。
AddJob() 是 Win32 API 中的一个函数，因此有这样一个宏 - 您可以

#undef AddJob

来解决您的问题。

Answer 2

在这里我们看到了宏的问题。

您的代码本身没有任何问题，问题出在Windows库上。实际上，Win32 标头中有一个名为 AddJob 的函数，但不完全是...不声明 Addjob 函数，而是声明 AddJobA 和 AddJobW 函数，分别处理非 unicode 和 unicode 字符串。

函数名称末尾的

A

是由于 Windows 标头中定义的宏定义的，该宏被定义为处理 unicode。本质上他们会有这样的东西：

#ifdef UNICODE
#  define AddJob AddJobW
#else
#  define AddJob AddJobA
#endif

这允许人们只使用

AddJob

并且宏会将函数指向正确的 unicode/非 unicode 函数。当然，问题是

#define

会影响一切，这就是你的函数所发生的情况。

要解决此问题，您可以

#undef AddJob

或简单地将函数名称更改为非 Win32 函数的名称。

Answer 3

Windows 函数可能在函数末尾有

A

或

W

-

A

表示 ASCII，

W

表示宽固定大小 unicode。您的项目设置决定使用哪个函数。如果您为项目启用了 unicode，addJob 可能会在最后有

W

..