第6.8章: inline 函数

English

概述

在上一章中，你了解到每个 .cpp 文件都变成一个独立的翻译单元， 并且每个非 inline 的函数定义必须恰好出现在一个翻译单元中。 否则链接器会报告重复定义错误。

但许多函数必须定义在头文件中：

inline 关键字解决了这个问题：它允许函数定义出现在多个 翻译单元中，而不违反单一定义规则（ODR）。

1. inline 的真正含义

inline 关键字并不表示“优化这个函数” 或“把函数体内联到调用点”。

相反，inline 表示：

这个函数可以出现在多个翻译单元中，链接器必须把所有完全相同的定义 视为同一个。

换言之，inline 关乎ODR 安全性， 而不是性能。

2. 为什么需要 inline

假设你把函数定义放在头文件中： 


// util.hpp
int add(int a, int b)
{
    return a + b;
}

并把它包含进两个翻译单元： 


// a.cpp
#include "util.hpp"

// b.cpp
#include "util.hpp"

链接器会看到两份 add 的定义并报错。

要解决这个问题，把函数标记为 inline： 


// util.hpp
inline int add(int a, int b)
{
    return a + b;
}

现在所有翻译单元都可以包含该定义，而链接器会把它们视为同一个。

3. 链接器对 inline 函数实际做了什么

链接器不会合并 inline 函数定义。 它做的是：

  1. 保留一个定义
  2. 丢弃所有其他完全相同的定义

这就是为什么不一致的 inline 定义会导致 IFNDR（非法、无需诊断）。如果两个 翻译单元含有不同的 inline 定义，链接器会 任意丢弃一些并保留一个。

所有 inline 定义必须逐位完全相同。

4. 示例：ODR 违规

下面是一个因违反单一定义规则而导致 IFNDR 的简单例子： 


// a.cpp
inline int f()
{
    return 1;
}


// b.cpp
inline int f()
{
    return 2;
}

两个翻译单元都能成功编译。但在链接时：

程序可能返回 1，也可能返回 2，取决于 链接器、构建选项，甚至目标文件的顺序。

这是真实的 ODR 违规，结果为 IFNDR。

5. inline 与符号生成（附汇编示例）

inline 函数的一个关键性质是：如果该函数从未被 ODR 使用， 编译器可以选择不生成可调用的符号。

考虑下面这段代码： 


int square(int num) {
    return num * num;
}

inline int inlinesquare(int num) {
    return num * num;
}

开启优化编译时，编译器会为 square 生成真实的符号： 


"square(int)":
        imul    edi, edi
        mov     eax, edi
        ret

但对于 inlinesquare，除非它真的被使用， 不会生成任何符号。

这体现了核心规则：

除非被使用，inline 函数可能完全不会生成任何汇编代码。

这是正常且符合预期的行为。

6. inline 与链接时优化（LTO）

使用 -flto 时，编译器能一次看到所有翻译单元。 这使它能够：

LTO 不会改变 inline 的含义，但它让符号生成 更可预测。

7. 真实世界的 ODR 违规：libstdc++ 加固

ODR 违规不只是理论问题。当链接同一个库用不同配置选项 编译出的两个版本时，真实程序里就会出现这种问题。

一个常见例子是 GCC 的 libstdc++ 在使用以下选项编译时： 


-D_GLIBCXX_ASSERTIONS

该选项为 std::vector、std::string 和 std::array 这类标准库容器启用边界检查。

如果你的程序链接了：

那么 <vector>、<string> 及其他头文件内部的 inline 定义就不是完全相同的。

链接器会：

这是隐蔽的 ODR 违规，会导致 IFNDR。在实践中，带边界检查的版本 常常被丢弃，于是即使你本意是启用加固，最终得到的却是 非检查版本。

8. 为什么 fast_io 容器避免了这个问题

fast_io 库完全避开了这一整类 ODR 问题：

由于 fast_io 容器不依赖单独编译的标准库内部隐藏的 inline 定义， 在混用不同构建配置时，它们不会受到困扰 std::vector 及其他标准容器 的那类 ODR 违规影响。

为了安全、一致性与可预测的行为，在性能关键或安全敏感的代码中， 建议优先使用 fast_io 容器，而不是标准库容器。

9. 每个函数都必须有存储类或链接性说明符

现代 C++ 风格遵循一条简单规则：

每个函数都必须用 extern、inline、 static 声明，或者放在匿名命名空间中。

这决定了：

你将在本教程后面学到更多存储类规则，包括：

10. inline 与模板

模板函数隐式就是 inline。 


template <typename T>
T twice(T x)
{
    return x + x;
}

这就是模板可以定义在头文件中而不造成 重复定义错误的原因。

11. inline 与模块

模块接口单元（.cppm）的行为像已编译的头文件。 定义在模块接口中的函数在跨翻译单元时自动 ODR 安全。

你不需要在模块接口中写 inline： 


// math.cppm
export module math;

export int square(int x)
{
    return x * x;   // implicitly ODR-safe
}

模块系统确保该定义只生成一次。

12. inline 不强制内联

无论是否有关键字 inline，编译器都可以自行决定内联 或不内联某个函数。

现代编译器根据优化启发式来决定内联，而不是根据 是否存在 inline。

这个关键字的存在是为了链接性与 ODR，而不是性能。

要点

← 第6.7章: 翻译单元 ↑ 主页 第6.9章: C 风格数组参数 →