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

例如：-

主.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

班级成员：

纯虚拟析构函数需要实现。

声明析构函数pure仍然需要定义它（与常规函数不同）：

struct X
{
    virtual ~X() = 0;
};
struct Y : X
{
    ~Y() {}
};
int main()
{
    Y y;
}
//X::~X(){} //uncomment this line for successful definition

这是因为在隐式销毁对象时调用基类析构函数，因此需要定义。

虚拟方法必须实现或定义为纯方法。

这类似于没有定义的非虚拟方法，增加了如下推理：纯声明会生成一个虚拟vtable，您可能会在不使用函数的情况下得到链接器错误：

struct X
{
    virtual void foo();
};
struct Y : X
{
   void foo() {}
};
int main()
{
   Y y; //linker error although there was no call to X::foo
}

要使其工作，请将X:：foo（）声明为纯：

struct X
{
    virtual void foo() = 0;
};

非虚拟类成员

即使未明确使用，也需要定义某些成员：

struct A
{ 
    ~A();
};

以下内容将产生错误：

A a;      //destructor undefined

实现可以在类定义本身中内联：

struct A
{ 
    ~A() {}
};

或外部：

A::~A() {}

如果实现在类定义之外，但在头中，则必须将方法标记为内联，以防止多重定义。

如果使用，则需要定义所有使用的成员方法。

一个常见的错误是忘记限定名称：

struct A
{
   void foo();
};

void foo() {}

int main()
{
   A a;
   a.foo();
}

定义应为

void A::foo() {}

静态数据成员必须在类外部的单个转换单元中定义：

struct X
{
    static int x;
};
int main()
{
    int x = X::x;
}
//int X::x; //uncomment this line to define X::x

可以为类定义中的整型或枚举类型的静态常量数据成员提供初始值设定项；然而，odr使用这个成员仍然需要如上所述的命名空间范围定义。C++11允许在类内初始化所有静态常量数据成员。

在我的例子中，语法是正确的，但当一个类调用同一DLL中的第二个类时，我出现了错误。第二个类的CPP文件在visual studio中具有错误的财产->项类型，在我的例子中，它被设置为C/C++头，而不是正确的C/C++编译器，因此编译器在构建CPP文件时没有编译它，并导致错误LNK2019

下面是一个示例，假设语法正确，您应该通过更改财产中的项类型来获得错误

//class A header file 
class ClassB; // FORWARD DECLERATION
class ClassA
{
public:
ClassB* bObj;
ClassA(HINSTANCE hDLL) ;
//  member functions
}
--------------------------------
//class A cpp file   
ClassA::ClassA(HINSTANCE hDLL) 
{
    bObj = new ClassB();// LNK2019 occures here 
    bObj ->somefunction();// LNK2019 occures here
}
/*************************/

//classB Header file
struct mystruct{}
class ClassB{
public:
ClassB();
mystruct somefunction();
}

------------------------------
//classB cpp file  
/* This is the file with the wrong property item type in visual studio --C/C++ Header-*/
ClassB::somefunction(){}
ClassB::ClassB(){}

尽管这是一个有多个公认答案的老问题，但我想分享如何解决一个晦涩的“未定义引用”错误。

不同版本的库

我使用别名来引用std:：filesystem：：path：filesystem自C++17以来就在标准库中，但我的程序也需要在C++14中编译，所以我决定使用变量别名：

#if (defined _GLIBCXX_EXPERIMENTAL_FILESYSTEM) //is the included filesystem library experimental? (C++14 and newer: <experimental/filesystem>)
using path_t = std::experimental::filesystem::path;
#elif (defined _GLIBCXX_FILESYSTEM) //not experimental (C++17 and newer: <filesystem>)
using path_t = std::filesystem::path;
#endif

假设我有三个文件：main.cpp、file.h、file.cpp：

file.h#include的＜实验：：filesystem＞，并包含上面的代码file.cpp，file.h的实现，#include的“file.h”main.cpp#include的<文件系统>和“file.h”

注意main.cpp和file.h中使用的不同库。由于main.cpp#在＜filesystem＞之后包含了“file.h”，所以这里使用的文件系统版本是C++17版本。我曾经用以下命令编译程序：

$g++-g-std=c++17-c main.cpp->将main.cpp编译为main.o$g++-g-std=c++17-c file.cpp->将file.cpp和file.h编译为file.o$g++-g-std=c++17-o可执行文件main.o file.o-lsdc++fs->链接main.o和file.o

这样，任何包含在file.o中并在main.o中使用的需要path_t的函数都会出现“未定义的引用”错误，因为main.o引用std:：filesystem：：path，而file.o引用的是std:：experimental：：filesystem:：path。

决议

为了解决这个问题，我只需要将file.h中的＜experimental：：filesystem＞更改为＜filesystem＞。

这是每个VC++程序员一再看到的最令人困惑的错误消息之一。让我们先把事情弄清楚。

A.什么是符号？简而言之，符号就是名称。它可以是变量名、函数名、类名、typedef名，或者除了那些属于C++语言的名称和符号之外的任何名称和符号。它由用户定义或由依赖库（另一个用户定义的）引入。

B.什么是外部的？在VC++中，每个源文件（.cpp、.c等）都被视为一个翻译单元，编译器一次编译一个单元，并为当前翻译单元生成一个目标文件（.obj）。（请注意，此源文件包含的每个头文件都将被预处理，并将被视为此翻译单元的一部分）翻译单元中的所有内容都被视为内部内容，其他所有内容都视为外部内容。在C++中，可以使用关键字extern、__declspec（dllimport）等引用外部符号。

C.什么是“决心”？Resolve是一个链接时间术语。在链接时，链接器尝试为对象文件中无法在内部找到其定义的每个符号找到外部定义。此搜索过程的范围包括：

编译时生成的所有对象文件显式或隐式的所有库（.lib）指定为此生成应用程序的附加依赖项。

此搜索过程称为解析。

D.最后，为什么是未解决的外部符号？如果链接器找不到内部没有定义的符号的外部定义，则会报告“未解决的外部符号”错误。

E.LNK2019的可能原因：未解决的外部符号错误。我们已经知道，此错误是由于链接器未能找到外部符号的定义所致，可能的原因如下：

定义已存在

例如，如果我们在.cpp中定义了一个名为foo的函数：

int foo()
{
    return 0;
}

在b.cpp中，我们希望调用函数foo，因此我们添加

void foo();

要声明函数foo（），并在另一个函数体中调用它，请使用bar（）：

void bar()
{
    foo();
}

现在，当您构建此代码时，您将收到一个LNK2019错误，抱怨foo是一个未解析的符号。在本例中，我们知道foo（）的定义在.cpp中，但与我们调用的定义不同（返回值不同）。这就是定义存在的情况。

定义不存在

如果我们想调用库中的某些函数，但导入库没有添加到项目设置的附加依赖项列表中（设置自：项目|财产|配置财产|链接器|输入|附加依赖项）。现在链接器将报告LNK2019，因为当前搜索范围中不存在该定义。

指定相互依赖的链接库的顺序是错误的。

如果库相互依赖，则库的链接顺序也很重要。通常，如果库A依赖于库B，那么在链接器标志中，libA必须出现在libB之前。

例如：

// B.h
#ifndef B_H
#define B_H

struct B {
    B(int);
    int x;
};

#endif

// B.cpp
#include "B.h"
B::B(int xx) : x(xx) {}

// A.h
#include "B.h"

struct A {
    A(int x);
    B b;
};

// A.cpp
#include "A.h"

A::A(int x) : b(x) {}

// main.cpp
#include "A.h"

int main() {
    A a(5);
    return 0;
};

创建库：

$ g++ -c A.cpp
$ g++ -c B.cpp
$ ar rvs libA.a A.o 
ar: creating libA.a
a - A.o
$ ar rvs libB.a B.o 
ar: creating libB.a
a - B.o

编译：

$ g++ main.cpp -L. -lB -lA
./libA.a(A.o): In function `A::A(int)':
A.cpp:(.text+0x1c): undefined reference to `B::B(int)'
collect2: error: ld returned 1 exit status
$ g++ main.cpp -L. -lA -lB
$ ./a.out

再说一遍，顺序很重要！