什么是未定义的参考/未解析的外部符号错误?常见原因是什么?如何解决/预防?
当前回答
需要考虑的一些拼写错误:(我作为初学者经常遇到)
如果您使用的是类:请检查您是否没有在定义函数的cpp文件中的函数名之前忘记“classname::”。如果使用forward声明:请确保声明正确的类型。例如:如果要转发声明“结构”,请使用“结构”而不是“类”。
其他回答
此外,如果您正在使用第三方库,请确保您拥有正确的32/64位二进制文件
需要考虑的一些拼写错误:(我作为初学者经常遇到)
如果您使用的是类:请检查您是否没有在定义函数的cpp文件中的函数名之前忘记“classname::”。如果使用forward声明:请确保声明正确的类型。例如:如果要转发声明“结构”,请使用“结构”而不是“类”。
模板实现不可见。
非专用模板的定义必须对使用它们的所有翻译单位可见。这意味着不能分离模板的定义到实现文件。如果必须分离实现,通常的解决方法是在头的末尾包含一个impl文件声明模板。常见的情况是:
template<class T>
struct X
{
void foo();
};
int main()
{
X<int> x;
x.foo();
}
//differentImplementationFile.cpp
template<class T>
void X<T>::foo()
{
}
要解决这个问题,必须将X::foo的定义移动到头文件或使用它的翻译单元可见的某个位置。
专用化模板可以在实现文件中实现,并且实现不必是可见的,但是必须事先声明专用化。
有关进一步的解释和另一种可能的解决方案(显式实例化),请参阅此问题和答案。
跨模块.dll(编译器特定)错误地导入/导出方法/类。
MSVS要求您使用__declspec(dllexport)和__declsspec(dllimport)指定要导出和导入的符号。
这种双重功能通常通过使用宏来实现:
#ifdef THIS_MODULE
#define DLLIMPEXP __declspec(dllexport)
#else
#define DLLIMPEXP __declspec(dllimport)
#endif
宏THIS_MODULE只能在导出函数的模块中定义。这样,声明:
DLLIMPEXP void foo();
扩展到
__declspec(dllexport) void foo();
并且告诉编译器导出函数,因为当前模块包含其定义。当将声明包含在不同的模块中时,它将扩展到
__declspec(dllimport) void foo();
并且告诉编译器,该定义位于链接到的一个库中(另请参见1)。
您可以使用类似的导入/导出类:
class DLLIMPEXP X
{
};
我正在构建一个共享/动态库。它在Linux和*BSD上运行,但在Mac OS X上,完全相同的编译和链接命令会产生未解决的引用错误。有什么好处?
Mac OS X在内部与Linux和*BSD非常不同。对象/可执行文件格式为
在Linux和*BSD上,当构建共享库时,默认情况下允许未解析的引用。期望它们在加载时能够满足主可执行文件和/或其他共享库的要求。如果在加载时无法解析这些符号,则共享库将无法加载。
在Mac OS X上,构建动态库时,默认情况下不允许未解析的引用。如果希望在加载时解析引用,则需要显式启用未解析的引用。这是使用未定义的dynamic_lookup链接器标志完成的。
在构建可加载插件时,允许未解析的引用非常有用。