Item 30：透彻了解 inline 的里里外外

从 inline 不是命令开始

inline int maxValue(int left, int right) {
    return left < right ? right : left;
}

很多人把 inline 读成“把函数体复制到每个调用点”。标准并不保证这一点；compiler 可以展开没有 inline keyword 的函数，也可以拒绝展开标记 inline 的函数。

Item 30 的原则是 Understand the ins and outs of inlining（透彻了解 inline 的内幕）。必须同时理解语言链接语义、优化器决定和工程交付成本。

两者相关但不等价。

inline 的第一职责是 ODR 语义

普通 external-linkage 函数在整个程序只能有一个定义。inline function 可在多个 translation units 出现相同定义，通常放在 header。

// metrics.hpp
inline double square(double value) {
    return value * value;
}

每个包含 header 的 translation unit 看见定义，linker/ODR 把它视为同一 inline entity。

这不要求最终机器码在每个 call site 展开；仍可存在 out-of-line copy。

实际展开由编译器成本模型决定

优化器考虑 body 可见性、大小、调用频率、递归、异常处理、register pressure 和目标 CPU。

同一函数在 hot loop 可能 inline，在 cold error path 保持 call。LTO 可让源文件外函数在 link-time 被展开，即使没有 inline keyword。

内联收益不只省一次 call

call 本身包含参数传递、返回地址和可能的 branch prediction 成本。更大的收益是打开跨函数优化：

inline int clampToByte(int value) {
    return value < 0 ? 0 : (value > 255 ? 255 : value);
}
 
int encode() {
    return clampToByte(42);
}

展开后 compiler 可 constant-fold 为 42，删除分支。

因此“函数调用开销很小”不能单独否定 inline 收益。

代码膨胀可能抵消收益

函数在 N 个 call sites 展开，body 指令可能复制 N 次，导致 code size（代码膨胀）。

大型可执行文件会增加磁盘、加载、重定位、memory page 和 cache 压力。

hot loop 内塞入多个大 inline bodies，可能让循环跨越更多 cache lines，产生 instruction-cache miss 和 front-end stall。

小而频繁不是按“源代码三行”判断，要看优化后的机器码与调用分布。

构造和析构函数可能比源码看起来大

空 constructor 仍会调用所有 base/member constructors，并在异常路径生成 cleanup；destructor 对成员/base 逆序销毁，polymorphic hierarchy 还涉及虚析构机制。

class Session : public BaseSession {
public:
    Session() = default;
 
private:
    std::string name_;
    std::vector<Record> records_;
    ResourceOwner owner_;
};

Session() = default 看似一行，展开后并不小。

class 内定义会隐式 inline

member function 直接定义在 class body 中，通常具有 implicit inline（隐式 inline）语义：

class Point {
public:
    int x() const noexcept { return x_; }
private:
    int x_;
};

这对 tiny accessor 合理，但大型业务 member 写在 class body 会无意扩大 header 与编译耦合。

不是所有类内函数都必须搬出；按稳定性、大小与可见性决定。

constexpr 与 template 的可见性不要混淆

现代 constexpr/consteval function 通常隐含 inline 语义；function template 通常必须在实例化点看见 definition，但“definition visible”不等于机器码一定展开。

template<class T>
T midpoint(T left, T right) {
    return left + (right - left) / 2;
}

template 可生成普通 out-of-line specialization，也可 inline；这是优化器决定。

header-only 不是“全部 inline 性能更高”的同义词。

virtual call 有时也能内联

virtual dispatch 通常在 runtime 选择 override，若 dynamic type 未知，compiler 不能直接替换唯一 body。

final class/function、local construction、whole-program/LTO 和 profile 信息可能支持 devirtualize 后 inline。

不要为了追求 inline 手工删除良好 virtual abstraction；先测量并让 compiler 利用类型信息。

取函数地址要求可调用实体

即使所有已知直接 calls 都展开，取函数地址或跨 ABI 调用仍需要一个可寻址 out-of-line body。

using Transform = int (*)(int);
Transform fn = &clampToByte;

inline 不保证函数“没有地址”或只存在复制体。

debugger 与 instrumentation 可能改变行为

debug builds 常关闭或限制优化，使 inline function 保留 call；release 展开后，断点可能映射多个位置、单步跳跃或局部变量被优化掉。

原书强调 debugger（调试器）可能无法像普通函数一样设置稳定断点；现代 DWARF/PDB 改善了体验，但优化后的 stepping 仍不等同源码执行顺序。

过度内联会改变 profiler attribution 和 tracing 粒度，需要用 inline stack 信息或显式 trace point。

头文件定义增加构建与发布耦合

inline body 改动会让所有包含者重新编译；prebuilt library 的客户机器码中可能已经 baked in 旧行为。

若只替换 shared library binary，客户内联的旧代码不会自动更新；安全修复可能要求客户 rebuild/redeploy。

稳定 ABI 库应谨慎 inline 会频繁修复或演进的逻辑，把边界函数留 out-of-line。

LTO 和 PGO 改变手工提示的价值

LTO 让实现即使在 source file 也可跨 translation unit inline；PGO 告诉优化器真实 hot paths。现代策略可先保持清晰边界，再由 whole-program optimization 选择。

compiler-specific force-inline/noinline attribute 应限制在测量证明的热点或工具边界，并保留 fallback。

不要以 attribute 代替 profile 和 assembly evidence。

用多维证据而不是源代码行数决策

先预测候选函数展开后 call count、text bytes、i-cache misses 和下游 rebuild 数，再运行验证：

• compiler optimization remarks 确认每个 call site 接受/拒绝原因。
• disassembly 检查 call 是否存在及常量传播结果。
• microbenchmark 与 end-to-end profile 同时测 latency/throughput。
• binary size、text section、page faults 和 instruction-cache events 对比。
• debug build 验证断点、单步、stack trace 与 sanitizer attribution。
• touch header 后统计 incremental rebuild translation units。
• shared-library patch 测试确认 client-baked code 是否需重编译。
• LTO/PGO on/off 组合避免只为单一 build configuration 优化。

默认先让 compiler 决定；只对稳定、短小、频繁且证据明确的函数强化 inline 倾向。

小结

• inline specifier 提供 ODR 多定义语义与优化提示，不强制 call-site expansion
• 实际 inlining 由 body 可见性、成本模型、热度、LTO/PGO 和 target 决定
• 展开可消除 call 并启用 constant propagation，但会造成 code size 与 instruction cache 压力
• class-body definition 是 implicit inline；constructor/destructor 的隐式工作可能远大于源码
• template definition visible、virtual devirtualization、function address 与实际 inline 是不同问题
• debugger、incremental build 和 client-baked implementation 都应进入 inline evidence matrix