我的例子：

头文件

class GameCharacter : public GamePart
{
    private:
        static vector<GameCharacter*> characterList;
...
}

.cpp文件：

vector<GameCharacter*> characterList;

这产生了“未定义”加载程序错误，因为“characterList”被声明为静态成员变量，但被定义为全局变量。

我加上这个是因为——虽然其他人在一长串需要注意的事情中列出了这个案例——但这个列表并没有给出示例。这是一个更值得寻找的例子，尤其是在C++中。

修复方法是向全局变量添加限定以定义静态数据成员：

vector<GameCharacter*> GameCharacter::characterList;

同时保持收割台相同。

正在添加模板。。。

给定带有友元运算符（或函数）的模板类型的代码片段；

template <typename T>
class Foo {
    friend std::ostream& operator<< (std::ostream& os, const Foo<T>& a);
};

运算符<<被声明为非模板函数。对于与Foo一起使用的每种类型T，都需要有一个非模板运算符<<。例如，如果声明了一个类型Foo＜int＞，那么必须有如下的运算符实现：；

std::ostream& operator<< (std::ostream& os, const Foo<int>& a) {/*...*/}

由于它未实现，链接器无法找到它并导致错误。

要更正此问题，可以在Foo类型之前声明一个模板运算符，然后将适当的实例化声明为友元。语法有点尴尬，但看起来如下：；

// forward declare the Foo
template <typename>
class Foo;

// forward declare the operator <<
template <typename T>
std::ostream& operator<<(std::ostream&, const Foo<T>&);

template <typename T>
class Foo {
    friend std::ostream& operator<< <>(std::ostream& os, const Foo<T>& a);
    // note the required <>        ^^^^
    // ...
};

template <typename T>
std::ostream& operator<<(std::ostream&, const Foo<T>&)
{
  // ... implement the operator
}

上述代码将运算符的友谊限制为Foo的相应实例化，即运算符＜＜＜int＞实例化被限制为访问Foo＜int＞的实例化的私有成员。

备选方案包括：；

允许友谊扩展到模板的所有实例化，如下所示；模板＜typename T＞Foo类{模板＜typename T1＞朋友std:：ostream&operator<<（std:：estream&os，const Foo<T1>/a）；// ...};或者，运算符<<的实现可以在类定义内内联完成；模板＜typename T＞Foo类{朋友std:：ostream&operator<<（std:：estream&os，const Foo&a）{ /*...*/ }// ...};

注意，当运算符（或函数）的声明仅出现在类中时，该名称不适用于“普通”查找，仅适用于cppreference中的依赖于参数的查找；

首先在类或类模板X中的友元声明中声明的名称将成为X最内部封闭命名空间的成员，但除非在命名空间范围内提供了匹配声明，否则无法进行查找（考虑X的依赖于参数的查找除外）。。。

cppreference和C++常见问题解答中有关于模板朋友的进一步阅读。

显示上述技术的代码列表。

---

作为失败代码示例的旁注；g++警告如下

警告：friend声明“std:：ostream&operator<<（…）”声明非模板函数[-Wnon-template friend]注意：（如果这不是您想要的，请确保函数模板已经声明，并在此处的函数名称后面添加<>）

编译C++程序分几个步骤进行，如2.2所述（Keith Thompson作为参考）：

翻译语法规则之间的优先顺序由以下阶段规定[参见脚注]。物理源文件字符以实现定义的方式映射到基本源字符集（为行尾指示符引入新的行尾字符）如果必需的[剪]将删除紧跟着换行符的反斜杠字符（\）的每个实例，将物理源行拼接到形成逻辑源线。[剪]源文件被分解为预处理标记（2.5）和空白字符序列（包括注释）。[剪]执行预处理指令，展开宏调用，并执行_Pragma一元运算符表达式。[剪]字符文本或字符串文本中的每个源字符集成员，以及每个转义序列和通用字符名在字符文本或非原始字符串文本中执行字符集的对应成员；[剪]连接相邻的字符串文字标记。分隔标记的空白字符不再有效。每个预处理令牌都转换为一个令牌。（2.7）对生成的令牌进行语法和语义分析翻译为翻译单元。[剪]翻译的翻译单元和实例化单元组合如下：[SNIP]解析所有外部实体引用。链接库组件以满足对未在中定义的实体的外部引用当前翻译。所有这样的转换器输出都被收集到包含执行所需信息的程序映像执行环境。（强调矿井）[脚注]尽管在实践中不同的阶段可能会被合并在一起，但实现必须表现得好像这些单独的阶段发生了一样。

指定的错误发生在编译的最后阶段，通常称为链接。这基本上意味着你把一堆实现文件编译成了对象文件或库，现在你想让它们一起工作。

假设您在.cpp中定义了符号a。现在，b.cpp声明了该符号并使用了它。在链接之前，它只是假设该符号是在某个地方定义的，但它并不在乎在哪里。链接阶段负责查找符号并将其正确链接到b.cpp（实际上，链接到使用它的对象或库）。

如果您使用的是Microsoft Visual Studio，您将看到项目生成.lib文件。其中包含导出符号表和导入符号表。导入的符号将根据链接的库进行解析，导出的符号将提供给使用该.lib的库（如果有）。

其他编译器/平台也存在类似的机制。

常见的错误消息包括错误LNK2001、错误LNK1120、错误LNK2019（适用于Microsoft Visual Studio）和未定义的对GCC symbolName的引用。

代码：

struct X
{
   virtual void foo();
};
struct Y : X
{
   void foo() {}
};
struct A
{
   virtual ~A() = 0;
};
struct B: A
{
   virtual ~B(){}
};
extern int x;
void foo();
int main()
{
   x = 0;
   foo();
   Y y;
   B b;
}

将使用GCC生成以下错误：

/home/AbiSfw/ccvvuHoX.o: In function `main':
prog.cpp:(.text+0x10): undefined reference to `x'
prog.cpp:(.text+0x19): undefined reference to `foo()'
prog.cpp:(.text+0x2d): undefined reference to `A::~A()'
/home/AbiSfw/ccvvuHoX.o: In function `B::~B()':
prog.cpp:(.text._ZN1BD1Ev[B::~B()]+0xb): undefined reference to `A::~A()'
/home/AbiSfw/ccvvuHoX.o: In function `B::~B()':
prog.cpp:(.text._ZN1BD0Ev[B::~B()]+0x12): undefined reference to `A::~A()'
/home/AbiSfw/ccvvuHoX.o:(.rodata._ZTI1Y[typeinfo for Y]+0x8): undefined reference to `typeinfo for X'
/home/AbiSfw/ccvvuHoX.o:(.rodata._ZTI1B[typeinfo for B]+0x8): undefined reference to `typeinfo for A'
collect2: ld returned 1 exit status

以及Microsoft Visual Studio中的类似错误：

1>test2.obj : error LNK2001: unresolved external symbol "void __cdecl foo(void)" (?foo@@YAXXZ)
1>test2.obj : error LNK2001: unresolved external symbol "int x" (?x@@3HA)
1>test2.obj : error LNK2001: unresolved external symbol "public: virtual __thiscall A::~A(void)" (??1A@@UAE@XZ)
1>test2.obj : error LNK2001: unresolved external symbol "public: virtual void __thiscall X::foo(void)" (?foo@X@@UAEXXZ)
1>...\test2.exe : fatal error LNK1120: 4 unresolved externals

常见原因包括：

未能链接到适当的库/对象文件或编译实现文件已声明和未定义的变量或函数。类类型成员的常见问题模板实现不可见。符号是在C程序中定义的，并在C++代码中使用。跨模块.dll错误地导入/导出方法/类。（特定于MSVS）循环库依赖关系对的未定义引用`WinMain@16'相互依赖的库顺序多个同名源文件使用#pragma（Microsoft Visual Studio）时键入错误或不包含.lib扩展名模板好友问题UNICODE定义不一致常量变量声明/定义中缺少“extern”（仅限C++）未为多文件项目配置Visual Studio代码在Mac OS X上构建dylib时出错，但在其他Unix-y系统上也可以

编译器/IDE中的错误

我最近遇到了这个问题，结果发现这是Visual Studio Express 2013中的一个错误。我不得不从项目中删除一个源文件，然后重新添加它以克服错误。

如果您认为这可能是编译器/IDE中的错误，请尝试以下步骤：

清理项目（一些IDE可以选择这样做，您也可以手动删除对象文件）尝试启动新项目，从原始代码复制所有源代码。

函数或类方法在源文件中使用内联说明符定义。

例如：-

主.cpp

#include "gum.h"
#include "foo.h"

int main()
{
    gum();
    foo f;
    f.bar();
    return 0;
}

foo.h（1）

#pragma once

struct foo {
    void bar() const;
};

口香糖.h（1）

#pragma once

extern void gum();

foo.cpp（1）

#include "foo.h"
#include <iostream>

inline /* <- wrong! */ void foo::bar() const {
    std::cout << __PRETTY_FUNCTION__ << std::endl;
}

gum.cpp（1）

#include "gum.h"
#include <iostream>

inline /* <- wrong! */ void gum()
{
    std::cout << __PRETTY_FUNCTION__ << std::endl;
}

如果指定gum（类似地，foo:：bar）在其定义中是内联的，那么编译器将通过以下方式内联gum（如果它选择）：-

没有任何独特的口香糖定义，因此不发出任何符号，链接器可以通过该符号引用口香糖的定义，而是将所有对gum的调用替换为编译后的gum主体的内联副本。

因此，如果在源文件gum.cpp中内联定义gum，则编译为对象文件gum.o，其中所有对gum的调用都是内联的并且没有定义接头可以指代口香糖的符号。当你将gum.o与另一个对象文件（例如main.o）链接到程序中引用外部符号gum时，链接器无法解析这些参考文献。因此连杆失效：

编译：

g++ -c  main.cpp foo.cpp gum.cpp

链接：

$ g++ -o prog main.o foo.o gum.o
main.o: In function `main':
main.cpp:(.text+0x18): undefined reference to `gum()'
main.cpp:(.text+0x24): undefined reference to `foo::bar() const'
collect2: error: ld returned 1 exit status

如果编译器可以在调用gum的每个源文件中看到它的定义，则只能将gum定义为内联。这意味着它的内联定义需要存在于包含在每个源文件中的头文件中您可以在其中调用gum。做两件事之一：

要么不内联定义

从源文件定义中删除内联说明符：

foo.cpp（2）

#include "foo.h"
#include <iostream>

void foo::bar() const {
    std::cout << __PRETTY_FUNCTION__ << std::endl;
}

gum.cpp（2）

#include "gum.h"
#include <iostream>

void gum()
{
    std::cout << __PRETTY_FUNCTION__ << std::endl;
}

重新生成：

$ g++ -c  main.cpp foo.cpp gum.cpp
imk@imk-Inspiron-7559:~/develop/so/scrap1$ g++ -o prog main.o foo.o gum.o
imk@imk-Inspiron-7559:~/develop/so/scrap1$ ./prog
void gum()
void foo::bar() const

成功

或正确内联

头文件中的内联定义：

foo.h（2）

#pragma once
#include <iostream>

struct foo {
    void bar() const  { // In-class definition is implicitly inline
        std::cout << __PRETTY_FUNCTION__ << std::endl;
    }
};
// Alternatively...
#if 0
struct foo {
    void bar() const;
};
inline void foo::bar() const  {
    std::cout << __PRETTY_FUNCTION__ << std::endl;
}
#endif

口香糖.h（2）

#pragma once
#include <iostream>

inline void gum() {
    std::cout << __PRETTY_FUNCTION__ << std::endl;
}

现在我们不需要foo.cpp或gum.cpp：

$ g++ -c main.cpp
$ g++ -o prog main.o
$ ./prog
void gum()
void foo::bar() const

链接的.lib文件与.dll关联

我也有同样的问题。假设我有项目MyProject和TestProject。我已经有效地将MyProject的lib文件链接到TestProject。然而，此lib文件是在构建MyProject的DLL时生成的。此外，我没有包含MyProject中所有方法的源代码，只包含对DLL入口点的访问。

为了解决这个问题，我将MyProject构建为LIB，并将TestProject链接到此.LIB文件（我将生成的.LIB文件复制粘贴到TestProject文件夹中）。然后我可以再次将MyProject构建为DLL。它正在编译，因为TestProject链接到的库确实包含MyProject中类中所有方法的代码。