C++ 对象模型与底层原理面试题 —— 从虚函数表到编译链接的深度问答

C++ 面试中，”底层原理”类问题是区分度最高的杀手锏——语法谁都会写，但能讲清楚虚函数表的内存布局、异常的栈展开流程、编译器怎么做 RVO 的人，往往就是那个拿到 offer 的。

这篇文章聚焦 C++ 对象模型和底层机制，每道题都配内存布局图，帮你从”会用”升级到”理解原理”。

---

第一部分：虚函数与多态

Q1：虚函数的底层实现机制是什么？

记忆点：每个含虚函数的类都有一个虚函数表（vtable），每个对象实例都有一个指向 vtable 的指针（vptr）。调用虚函数时，通过 vptr 找到 vtable，再从表中找到函数地址。这就是动态绑定（运行时多态）。

对象内存布局（含虚函数）：

class Base {
    virtual void func1();
    virtual void func2();
    int x;
};

Base 对象的内存：
┌──────────────────┐
│ vptr (8 bytes)   │ → 指向 Base::vtable
├──────────────────┤
│ x    (4 bytes)   │
├──────────────────┤
│ padding (4 bytes)│
└──────────────────┘
sizeof(Base) = 16 (64位系统)

Base::vtable（编译期生成，每个类一份）：
┌──────────────────┐
│ &Base::func1     │  slot 0
├──────────────────┤
│ &Base::func2     │  slot 1
└──────────────────┘

class Derived : public Base {
    void func1() override;  // 重写 func1
    virtual void func3();   // 新增虚函数
    int y;
};

Derived::vtable：
┌──────────────────┐
│ &Derived::func1  │  slot 0 ← 被覆盖了！
├──────────────────┤
│ &Base::func2     │  slot 1 ← 继承未重写
├──────────────────┤
│ &Derived::func3  │  slot 2 ← 新增
└──────────────────┘

虚函数调用过程：
  Base* p = new Derived();
  p->func1();
  // 1. p → 对象内存 → 取 vptr
  // 2. vptr → Derived::vtable
  // 3. vtable[0] → &Derived::func1
  // 4. 调用 Derived::func1()

面试加分：

• vptr 通常在对象内存的最开头（GCC/Clang/MSVC 都是），这是为了快速访问
• vtable 是每个类一份，不是每个对象一份，存在只读数据段
• 构造函数中 vptr 会被分阶段设置——先设为基类的 vtable，再设为派生类的 vtable。所以构造函数中调用虚函数不会多态

Q2：为什么构造函数不能是虚函数？析构函数为什么要是虚函数？

记忆点：构造函数不能是虚函数——对象还没构造完，vptr 还没设好，无法走 vtable 找函数。析构函数必须是虚函数（当有继承时）——否则通过基类指针 delete 派生类对象只会调基类析构，派生类资源泄漏。

class Base {
public:
    virtual ~Base() { cout << "~Base" << endl; }
};

class Derived : public Base {
    int* data;
public:
    Derived() : data(new int[100]) {}
    ~Derived() override { delete[] data; cout << "~Derived" << endl; }
};

Base* p = new Derived();
delete p;
// 如果 ~Base() 不是虚函数：只调用 ~Base() → data 内存泄漏！
// 如果 ~Base() 是虚函数：先 ~Derived() 再 ~Base() → 正确释放

析构顺序（虚析构时）：
  delete p;
  → vptr → vtable → &Derived::~Derived
  → 执行 Derived::~Derived()（释放 data）
  → 自动调用 Base::~Base()
  → 释放对象内存

规则：
  ✓ 有虚函数的类 → 析构函数必须 virtual
  ✓ 作为基类设计的类 → 析构函数 virtual
  ✗ 不会被继承的类 → 不需要 virtual（避免不必要的 vptr 开销）
  ✗ 如果类有 final 标记 → 不需要 virtual

Q3：多重继承的对象内存布局是怎样的？

记忆点：多重继承的对象包含多个 vptr——每个基类一个。派生类对象的指针在向上转换（upcast）时可能需要地址偏移。

class A { virtual void fa(); int a; };
class B { virtual void fb(); int b; };
class C : public A, public B { void fa() override; int c; };

C 对象的内存布局：
┌──────────────────┐ ← C* 和 A* 指向这里
│ vptr_A (8 bytes) │ → C-in-A vtable（包含 C::fa）
├──────────────────┤
│ a    (4 bytes)   │
├──────────────────┤
│ padding          │
├──────────────────┤ ← B* 指向这里（偏移了 16 字节！）
│ vptr_B (8 bytes) │ → C-in-B vtable（包含 B::fb）
├──────────────────┤
│ b    (4 bytes)   │
├──────────────────┤
│ c    (4 bytes)   │
└──────────────────┘

关键点：
  C* pc = new C();
  A* pa = pc;        // pa == pc，地址不变
  B* pb = pc;        // pb == pc + 16！编译器自动加偏移
  C* pc2 = static_cast<C*>(pb);  // pc2 == pb - 16！编译器自动减偏移

面试加分： 这就是为什么你不能随意用 reinterpret_cast 在多重继承类之间转换——它不会调整偏移。必须用 static_cast 或 dynamic_cast。

Q4：菱形继承和虚继承是怎么回事？

记忆点：菱形继承 = A 被 B 和 C 同时继承，D 继承 B 和 C。问题：D 中有两份 A 的副本。解决方案：虚继承（virtual inheritance），让 B 和 C 虚继承 A，D 中只有一份 A。代价：多了虚基类指针，访问变慢。

菱形继承（无虚继承）：
       A
      / \
     B   C       ← B 和 C 各有一份 A
      \ /
       D         ← D 有两份 A！访问 A 的成员有歧义

菱形继承（虚继承）：
       A
      / \
     B   C       ← B : virtual public A, C : virtual public A
      \ /
       D         ← D 只有一份 A

D 的内存布局（虚继承时）：
┌──────────────────┐
│ B 的部分          │  包含 vptr_B + 虚基类偏移指针
│ (指向 A 的偏移)   │
├──────────────────┤
│ C 的部分          │  包含 vptr_C + 虚基类偏移指针
│ (指向 A 的偏移)   │
├──────────────────┤
│ D 自己的成员       │
├──────────────────┤
│ A 的部分（共享）   │  ← 只有一份，在对象末尾
└──────────────────┘

虚继承的代价：
  ├── 多了虚基类表指针（或合并到 vtable）
  ├── 访问虚基类成员需要间接寻址（慢）
  ├── 构造函数更复杂（最终派生类负责构造虚基类）
  └── sizeof 更大

面试加分： 实际工程中应尽量避免菱形继承。如果需要，考虑用组合替代继承，或用接口（纯虚类）替代。C++ STL 中 iostream 就是菱形继承的经典例子（istream 和 ostream 虚继承 ios_base）。

Q5：虚函数的性能开销有多大？什么时候不该用？

记忆点：虚函数调用比普通函数调用多一次指针间接寻址（约 1-2 个时钟周期），主要开销不在间接调用本身，而在于阻止内联优化和可能的 cache miss。

普通函数调用：
  call Base::func1      ← 编译期确定地址，可以内联

虚函数调用：
  mov rax, [rdi]        ← 加载 vptr
  call [rax + offset]   ← 通过 vtable 间接调用，不能内联

性能影响：
  间接调用本身：~1-2 个周期，影响很小
  阻止内联：影响可能很大！内联能消除调用开销 + 允许更多优化
  icache miss：vtable 分散在内存中，可能导致指令缓存缺失

不该用虚函数的场景：
  ├── 热循环中高频调用的小函数（内联更重要）
  ├── 性能极度敏感的底层代码（如分配器、序列化器）
  ├── 类不会被继承（加 final 让编译器去虚化）
  └── 只需要编译期多态时（用 CRTP 或模板替代）

替代方案：
  ├── CRTP（Curiously Recurring Template Pattern）：编译期多态
  ├── std::variant + std::visit：类型安全的运行时多态
  ├── 函数指针 / std::function：轻量级回调
  └── if constexpr：编译期分支

---

第二部分：异常处理

Q6：C++ 异常的底层实现机制？

记忆点：C++ 异常使用”零开销异常”模型（table-based）——正常执行路径没有额外开销，但抛出异常时代价很高（需要栈展开 stack unwinding）。编译器为每个函数生成异常表（exception table），记录 try/catch 的范围和类型信息。

异常处理流程：

  throw MyException("error");
  │
  ├── 1. 在堆上分配异常对象
  ├── 2. 调用 __cxa_throw()
  │      ├── 查找当前函数的异常表
  │      ├── 没有匹配的 catch → 栈展开
  │      │   ├── 调用当前栈帧中局部对象的析构函数（RAII 释放）
  │      │   ├── 弹出栈帧
  │      │   └── 检查上一层函数的异常表 → 重复
  │      └── 找到匹配的 catch → 跳转到 catch 代码块
  └── 3. catch 处理完毕，销毁异常对象

零开销 vs 传统方案（setjmp/longjmp）：
  ┌──────────────┬──────────────┬──────────────┐
  │              │ 正常路径开销  │ 抛出异常开销  │
  ├──────────────┼──────────────┼──────────────┤
  │ 零开销(现代)  │ 零            │ 很高（查表+展开）│
  │ setjmp/longjmp│ 有（保存寄存器）│ 中等          │
  └──────────────┴──────────────┴──────────────┘

  现代编译器都用零开销模型 → 异常是"不抛就免费，抛了就很贵"

Q7：异常安全的三个级别？

记忆点：基本保证（不泄漏）→ 强保证（要么成功要么回滚）→ 无抛出保证（绝不抛异常）。RAII 是实现异常安全的核心工具。

三个级别：
  ┌──────────────┬───────────────────────────────────────┐
  │ 级别          │ 含义                                   │
  ├──────────────┼───────────────────────────────────────┤
  │ 基本保证      │ 异常后对象处于有效但未指定的状态         │
  │ (basic)      │ 不泄漏资源，不违反不变量               │
  ├──────────────┼───────────────────────────────────────┤
  │ 强保证        │ 异常后状态回滚到操作之前（commit or     │
  │ (strong)     │ rollback 语义）                       │
  ├──────────────┼───────────────────────────────────────┤
  │ 无抛出保证    │ 操作绝不抛出异常                       │
  │ (nothrow)    │ 标记 noexcept，析构函数默认 noexcept   │
  └──────────────┴───────────────────────────────────────┘

// 基本保证（RAII 自动做到）
void basicSafe() {
    auto p = make_unique<int>(42);  // RAII：异常时自动释放
    riskyOperation();                // 可能抛异常
    // p 析构时自动 delete，不泄漏
}

// 强保证（copy-and-swap 惯用法）
class MyClass {
    vector<int> data;
public:
    MyClass& operator=(const MyClass& other) {
        MyClass temp(other);    // 先拷贝（如果抛异常，this 不受影响）
        swap(data, temp.data);  // swap 是 noexcept 的
        return *this;           // temp 析构释放旧数据
    }
};

// 无抛出保证
void safeCleanup() noexcept {
    // 析构函数、swap、移动操作应该是 noexcept
}

面试加分： noexcept 不仅是文档——它影响性能。标记 noexcept 的移动构造函数会让 vector::push_back 在扩容时用移动而非拷贝（因为扩容需要强保证，只有 noexcept 的移动才能保证不回退）。

Q8：什么时候该用异常，什么时候用错误码？

记忆点：异常用于”异常情况”（不应该频繁发生），错误码用于”预期中的失败”。构造函数和运算符重载必须用异常（没有返回值）。性能关键路径避免异常。

选择指南：
  ┌──────────────────────────┬────────────┬────────────┐
  │ 场景                     │ 异常        │ 错误码      │
  ├──────────────────────────┼────────────┼────────────┤
  │ 构造函数失败              │ ✓ 唯一选择  │ ✗          │
  │ 运算符重载失败            │ ✓ 唯一选择  │ ✗          │
  │ 资源分配失败（内存/文件）  │ ✓          │            │
  │ 编程错误（越界/空指针）    │ assert     │ ✗          │
  │ 文件不存在/网络超时       │            │ ✓ 预期的   │
  │ 热循环中的操作            │ ✗ 太慢     │ ✓          │
  │ 跨模块/跨语言边界        │ ✗          │ ✓          │
  └──────────────────────────┴────────────┴────────────┘

  现代 C++ 趋势：
  ├── std::optional → 可能没有值的返回
  ├── std::expected (C++23) → 值或错误
  ├── std::error_code → 系统错误
  └── 异常仍然是主流方式（Google 除外）

---

第三部分：值类别与移动语义

Q9：C++ 的值类别体系是什么？

记忆点：每个表达式有两个属性——有没有身份（identity）、能不能被移动（movable）。组合出五种值类别：lvalue（有身份不可移动）、xvalue（有身份可移动）、prvalue（无身份可移动）。glvalue = lvalue + xvalue，rvalue = xvalue + prvalue。

值类别关系图：
                  expression
                 /          \
              glvalue       rvalue
             /     \       /     \
          lvalue   xvalue      prvalue

  lvalue（左值）：有名字，可以取地址
    例：变量名 x、*p、a[0]、字符串字面量 "hello"

  prvalue（纯右值）：临时值，没有名字
    例：42、x+y、func()（返回非引用）、lambda

  xvalue（将亡值）：有身份但即将被移动
    例：std::move(x)、static_cast<T&&>(x)、func()（返回 T&&）

  记忆口诀：
  "左值有地址，右值是临时，将亡值要搬家"

Q10：std::move 到底做了什么？

记忆点：std::move 什么都没”移动”！它只是一个 static_cast<T&&>，把左值强制转换为右值引用（xvalue），让后续操作可以匹配移动构造/移动赋值。真正的”移动”发生在移动构造函数里。

// std::move 的实现（简化）
template<typename T>
constexpr remove_reference_t<T>&& move(T&& t) noexcept {
    return static_cast<remove_reference_t<T>&&>(t);
}

// 使用示例
string a = "hello";
string b = std::move(a);  // a 变成 xvalue → 匹配 string(string&&)
// 此时 a 处于"有效但未指定"状态（通常是空串）

// 常见错误
const string c = "world";
string d = std::move(c);  // const string&& 不能匹配 string(string&&)
                           // 退化为拷贝构造！move 了个寂寞！

Q11：完美转发是怎么实现的？

记忆点：完美转发 = 万能引用（T&&）+ std::forward + 引用折叠。目的：让包装函数把参数原封不动地传给内部函数，保持原来的值类别（左值还是左值，右值还是右值）。

引用折叠规则（编译器自动应用）：
  T& &   → T&     （左引用 + 左引用 = 左引用）
  T& &&  → T&     （左引用 + 右引用 = 左引用）
  T&& &  → T&     （右引用 + 左引用 = 左引用）
  T&& && → T&&    （右引用 + 右引用 = 右引用）

  记忆：只要有一个 & 就折叠为 &，两个 && 才是 &&

// 完美转发模板
template<typename T>
void wrapper(T&& arg) {               // T&& 是万能引用（不是右值引用！）
    inner(std::forward<T>(arg));        // forward 保持值类别
}

int x = 42;
wrapper(x);          // T = int&,  arg 类型 = int& （左值）
                     // forward<int&>(arg) → 转发为左值
wrapper(42);         // T = int,   arg 类型 = int&& （右值）
                     // forward<int>(arg) → 转发为右值

// std::forward 的本质
template<typename T>
T&& forward(remove_reference_t<T>& t) noexcept {
    return static_cast<T&&>(t);  // 利用引用折叠
}
// 当 T = int&:  static_cast<int& &&>(t) → static_cast<int&>(t)  → 左值
// 当 T = int:   static_cast<int&&>(t)                            → 右值

Q12：RVO 和 NRVO 是什么？

记忆点：RVO（Return Value Optimization）和 NRVO（Named RVO）是编译器优化——直接在调用者的内存空间构造返回值，跳过拷贝/移动。C++17 起 RVO 是强制的（mandatory copy elision），NRVO 仍然是可选优化。

// RVO（返回临时对象）—— C++17 起强制优化
string makeString() {
    return string("hello");  // 直接在调用者的空间构造，零拷贝
}

// NRVO（返回命名对象）—— 可选优化，大多数编译器都会做
string makeString2() {
    string s = "hello";
    s += " world";
    return s;  // 编译器通常直接在调用者空间构造 s
}

// NRVO 失效的情况
string bad() {
    string a = "hello";
    string b = "world";
    if (condition)
        return a;  // 编译器不知道返回 a 还是 b → NRVO 可能失效
    else
        return b;  // 但仍然可以走移动构造
}

优化优先级：
  1. RVO/NRVO（零开销，编译器自动做）
  2. 移动构造（如果 RVO 失效）
  3. 拷贝构造（最后手段）

面试加分：不要写 return std::move(local_var);
  → 这反而阻止了 NRVO！让编译器自己优化
  → 只有返回成员变量或参数时才需要 std::move

---

第四部分：RTTI 与类型转换

Q13：C++ 四种类型转换的区别？

记忆点：static_cast（编译期，已知类型的安全转换）、dynamic_cast（运行时，多态类型的安全向下转换）、const_cast（去 const）、reinterpret_cast（暴力重新解释比特位）。面试口诀：”静态知类型，动态查虚表，const 去只读，reinterpret 很危险”。

┌──────────────────┬─────────────────────────────────────────┐
│ 转换              │ 用途和安全性                              │
├──────────────────┼─────────────────────────────────────────┤
│ static_cast      │ 已知安全的转换：数值类型、void*、         │
│                  │ 向上转换、已知类型的向下转换               │
│                  │ 编译期检查，不查 vtable                  │
├──────────────────┼─────────────────────────────────────────┤
│ dynamic_cast     │ 多态类型的向下转换                       │
│                  │ 运行时通过 RTTI 检查，失败返回 nullptr    │
│                  │ 需要虚函数表（至少有一个 virtual）         │
├──────────────────┼─────────────────────────────────────────┤
│ const_cast       │ 去除 const/volatile                     │
│                  │ 不改变底层类型，只改变 cv 限定符           │
├──────────────────┼─────────────────────────────────────────┤
│ reinterpret_cast │ 指针/引用之间的暴力转换                   │
│                  │ 不检查任何东西，极度危险                   │
│                  │ 用于底层 hack（如序列化、硬件地址）        │
└──────────────────┴─────────────────────────────────────────┘

// dynamic_cast 示例
class Base { virtual ~Base() {} };
class Derived : public Base { void special(); };

Base* p = getObject();
Derived* d = dynamic_cast<Derived*>(p);  // 安全向下转换
if (d) {
    d->special();  // 确认是 Derived 才调用
} else {
    // p 不是 Derived 类型
}

// dynamic_cast 引用版本：失败抛 std::bad_cast
Derived& d2 = dynamic_cast<Derived&>(*p);  // 失败抛异常

Q14：RTTI 的原理和开销？

记忆点：RTTI（Run-Time Type Information）= typeid + dynamic_cast。底层通过 vtable 中存储的 type_info 指针实现。开销：每个多态类多一个 type_info 对象，dynamic_cast 需要遍历继承链匹配类型。

RTTI 的底层机制：

vtable 结构（实际上比之前画的多一些东西）：
┌──────────────────┐
│ type_info*       │  ← RTTI 信息（类名、继承关系）
├──────────────────┤
│ offset_to_top    │  ← 到对象顶部的偏移（多重继承用）
├──────────────────┤
│ &func1           │  slot 0
├──────────────────┤
│ &func2           │  slot 1
└──────────────────┘

typeid 的使用：
  Base* p = new Derived();
  cout << typeid(*p).name();  // 输出 Derived 的类型名
  // 注意：typeid(*p) 不是 typeid(p)！后者是 Base* 的类型

禁用 RTTI：
  编译选项 -fno-rtti（GCC/Clang）或 /GR-（MSVC）
  → 不能用 dynamic_cast 和 typeid
  → 减小二进制体积
  → Google C++ Style Guide 建议禁用 RTTI

---

第五部分：编译与链接

Q15：C++ 程序从源代码到可执行文件经历了哪些步骤？

记忆点：四步——预处理（#include/#define 展开）→ 编译（生成汇编）→ 汇编（生成目标文件 .o）→ 链接（合并目标文件，解析符号引用）。

编译流程：

  main.cpp ──预处理──→ main.i ──编译──→ main.s ──汇编──→ main.o ──┐
  util.cpp ──预处理──→ util.i ──编译──→ util.s ──汇编──→ util.o ──┤──链接──→ a.out
                                                    libstd.a ──┘

  gcc -E main.cpp -o main.i    # 预处理
  gcc -S main.i -o main.s      # 编译（生成汇编）
  gcc -c main.s -o main.o      # 汇编（生成目标文件）
  gcc main.o util.o -o a.out   # 链接

各阶段做了什么：
  ┌──────────┬────────────────────────────────────────────┐
  │ 预处理    │ #include 展开、#define 替换、#ifdef 条件编译  │
  │          │ 去注释、行号标记                              │
  ├──────────┼────────────────────────────────────────────┤
  │ 编译      │ 词法分析 → 语法分析 → 语义分析 → 生成 IR      │
  │          │ 优化 → 生成汇编代码                          │
  ├──────────┼────────────────────────────────────────────┤
  │ 汇编      │ 汇编代码 → 机器码（目标文件 .o/.obj）         │
  │          │ 包含代码段、数据段、符号表、重定位表           │
  ├──────────┼────────────────────────────────────────────┤
  │ 链接      │ 合并所有 .o 的各段                           │
  │          │ 符号解析（找到函数/变量的定义）               │
  │          │ 重定位（填入最终地址）                        │
  │          │ 生成可执行文件                               │
  └──────────┴────────────────────────────────────────────┘

Q16：静态链接和动态链接的区别？

记忆点：静态链接把库代码复制到可执行文件中，运行时不依赖外部库。动态链接只记录引用，运行时才加载库（.so/.dll）。动态链接节省磁盘和内存（共享），但有运行时开销和版本兼容问题。

静态链接 vs 动态链接：
  ┌──────────────┬──────────────────┬──────────────────┐
  │              │ 静态链接           │ 动态链接           │
  ├──────────────┼──────────────────┼──────────────────┤
  │ 库文件        │ .a (Linux)       │ .so (Linux)      │
  │              │ .lib (Windows)   │ .dll (Windows)   │
  │ 可执行文件大小 │ 大（包含库代码）  │ 小（只有引用）    │
  │ 运行依赖      │ 无              │ 需要库文件存在     │
  │ 更新库        │ 需要重新链接     │ 替换 .so 即可     │
  │ 内存占用      │ 每个进程各一份   │ 多进程共享一份     │
  │ 加载速度      │ 快              │ 首次加载稍慢      │
  │ 符号解析时机  │ 编译时          │ 加载时/运行时      │
  └──────────────┴──────────────────┴──────────────────┘

动态库加载方式：
  ├── 隐式链接：编译时指定 -l，程序启动时自动加载
  └── 显式链接：dlopen/dlsym（Linux）或 LoadLibrary/GetProcAddress（Windows）

常见面试问题：
  Q: 符号冲突怎么办？
  A: 静态库的符号会冲突（链接错误），动态库可以用版本脚本控制导出符号

  Q: extern "C" 干什么用？
  A: 禁止 C++ 的名字修饰（name mangling），让 C 代码能找到 C++ 函数
     → C++ 编译器会把 func(int) 变成 _Z4funci，extern "C" 保持为 func

Q17：ODR 违反和头文件中的常见陷阱？

记忆点：ODR（One Definition Rule）= 每个实体在整个程序中只能有一个定义。头文件中定义非 inline 函数/变量会导致多重定义错误。解决方案：inline、static、匿名 namespace、constexpr、header-only。

ODR 违反的典型场景：

// util.h
int helper() { return 42; }    // ✗ 每个包含这个头的 .cpp 都有一份定义

// a.cpp
#include "util.h"              // helper 定义 1
// b.cpp
#include "util.h"              // helper 定义 2
// 链接时：multiple definition of 'helper'

解决方案：
  ┌──────────────────┬────────────────────────────────────┐
  │ 方式              │ 用法                                │
  ├──────────────────┼────────────────────────────────────┤
  │ 声明+定义分离     │ .h 只声明，.cpp 定义                 │
  │ inline           │ inline int helper() { ... }        │
  │                  │ 允许多个相同定义（编译器只保留一份）   │
  │ static           │ static int helper() { ... }        │
  │                  │ 每个编译单元独立一份（内部链接）       │
  │ constexpr        │ constexpr int helper() { ... }     │
  │                  │ 隐式 inline                         │
  │ inline 变量(C++17)│ inline int x = 42;（头文件中定义）   │
  │ 匿名 namespace   │ namespace { int helper() {...} }    │
  └──────────────────┴────────────────────────────────────┘

头文件保护：
  #pragma once           ← 简洁，主流编译器都支持
  或
  #ifndef UTIL_H
  #define UTIL_H
  ...
  #endif

---

第六部分：内存管理深入

Q18：C++ 内存区域划分？

记忆点：五大区——栈（局部变量，自动管理，向下增长）、堆（new/malloc，手动管理）、全局/静态区（全局变量、static 变量）、常量区（字符串字面量、const）、代码区（函数代码）。

进程虚拟地址空间（Linux x86-64）：
┌──────────────────────┐ 0x7FFF...  高地址
│        栈 (Stack)     │ ← 局部变量、函数参数、返回地址
│        ↓ 向下增长      │    自动分配释放，大小有限（默认 8MB）
│                       │
│        ↑ 向上增长      │
│        堆 (Heap)      │ ← new/malloc 分配
│                       │    手动管理（或智能指针）
├──────────────────────┤
│   BSS（未初始化数据）  │ ← 未初始化的全局/静态变量
├──────────────────────┤
│   Data（已初始化数据） │ ← 已初始化的全局/静态变量
├──────────────────────┤
│   Text（代码段）       │ ← 机器指令，只读
└──────────────────────┘ 0x0000...  低地址

各区域特点：
  栈：速度极快（移动栈指针即可），LIFO，线程独立
  堆：速度较慢（需要分配器管理），碎片化问题
  全局区：程序启动时分配，结束时释放
  常量区：只读，修改会 SIGSEGV

Q19：placement new 是什么？什么时候用？

记忆点：placement new 在已分配的内存上构造对象，不分配新内存。用途：内存池、自定义分配器、共享内存上构造对象。必须手动调用析构函数。

// 普通 new：分配内存 + 构造对象
MyClass* p = new MyClass(args);

// placement new：在指定地址构造对象
char buffer[sizeof(MyClass)];                    // 已有的内存
MyClass* p = new (buffer) MyClass(args);          // 在 buffer 上构造

// 必须手动析构（不能 delete！因为内存不是 new 分配的）
p->~MyClass();

// 典型用途：内存池
class MemoryPool {
    char* pool;
    size_t offset = 0;
public:
    template<typename T, typename... Args>
    T* construct(Args&&... args) {
        void* addr = pool + offset;
        offset += sizeof(T);
        return new (addr) T(std::forward<Args>(args)...);  // placement new
    }
};

Q20：内存对齐的规则？为什么需要对齐？

记忆点：CPU 按字长访问内存（如 8 字节），未对齐的访问可能需要两次内存访问。编译器自动对齐：每个成员对齐到自身大小的整数倍地址，结构体总大小对齐到最大成员大小的整数倍。

struct Bad {
    char  a;   // offset 0, size 1
               // padding 7 bytes（对齐 b 到 8 的倍数）
    double b;  // offset 8, size 8
    char  c;   // offset 16, size 1
               // padding 7 bytes（总大小对齐到 8 的倍数）
};
// sizeof(Bad) = 24（只有 10 字节有效数据！）

struct Good {
    double b;  // offset 0, size 8
    char  a;   // offset 8, size 1
    char  c;   // offset 9, size 1
               // padding 6 bytes
};
// sizeof(Good) = 16（节省了 8 字节）

// 规则：按成员大小从大到小排列，减少 padding

对齐控制：
  alignof(T)           → 查询类型 T 的对齐要求
  alignas(N)           → 指定对齐要求
  #pragma pack(1)      → 强制 1 字节对齐（取消 padding，可能影响性能）

面试常考：
  Q: 空类的大小是多少？
  A: 1 字节（保证每个对象有唯一地址）

  Q: 含虚函数的空类？
  A: 8 字节（64 位系统，一个 vptr）

  Q: 空基类优化（EBO）？
  A: 当空类作为基类时，不占空间（sizeof 不计入）
     → 这就是为什么 STL 用继承存 comparator/allocator

---

第七部分：模板编译模型

Q21：模板为什么要在头文件中定义？

记忆点：模板是”蓝图”，编译器在实例化时才生成代码。如果模板定义在 .cpp 中，其他编译单元看不到定义，无法实例化 → 链接错误。解决方案：定义在头文件中、显式实例化、extern template。

问题场景：
  // util.h
  template<typename T>
  T add(T a, T b);           // 只有声明

  // util.cpp
  template<typename T>
  T add(T a, T b) { return a + b; }  // 定义在 .cpp

  // main.cpp
  #include "util.h"
  int x = add(1, 2);         // 编译器要实例化 add<int>
                              // 但看不到定义！→ 链接错误

解决方案：
  ① 定义在头文件中（最常用）
     // util.h
     template<typename T>
     T add(T a, T b) { return a + b; }

  ② 显式实例化（.cpp 末尾列出所有需要的类型）
     // util.cpp
     template int add<int>(int, int);
     template double add<double>(double, double);

  ③ extern template（C++11，防止重复实例化）
     // 在某个 .cpp 中实例化
     template class vector<int>;
     // 在其他 .cpp 中声明（不要再实例化了）
     extern template class vector<int>;

Q22：SFINAE 是什么？enable_if 怎么用？

记忆点：SFINAE = “Substitution Failure Is Not An Error”。模板参数替换失败时不报错，而是从候选集中移除。enable_if 利用 SFINAE 在编译期根据条件启用/禁用函数重载。C++20 的 Concepts 是更优雅的替代。

// enable_if 基础用法：只对整数类型启用
template<typename T>
typename enable_if<is_integral<T>::value, T>::type
myAbs(T x) {
    return x < 0 ? -x : x;
}

// C++17 简化写法
template<typename T>
auto myAbs(T x) -> enable_if_t<is_integral_v<T>, T> {
    return x < 0 ? -x : x;
}

// C++20 最优雅：Concepts
template<integral T>
T myAbs(T x) {
    return x < 0 ? -x : x;
}
// 或者
auto myAbs(integral auto x) {
    return x < 0 ? -x : x;
}

---

第八部分：高频综合题

Q23：一个 C++ 对象从创建到销毁，底层发生了什么？

记忆点：new Derived() = operator new（分配内存）→ 基类构造（设 vptr 为基类 vtable）→ 成员初始化 → 派生类构造体（设 vptr 为派生类 vtable）。delete p = 虚析构（派生类析构 → 基类析构）→ operator delete（释放内存）。

Derived* p = new Derived(42);

底层步骤：
  1. operator new(sizeof(Derived))    → 分配堆内存
  2. 在分配的内存上构造对象：
     a. 调用 Base::Base()
        → vptr 设为 &Base::vtable
        → 初始化 Base 的成员
     b. 调用 Derived::Derived(42)
        → vptr 设为 &Derived::vtable（覆盖基类的）
        → 初始化 Derived 的成员
  3. 返回指针

delete p;  // p 是 Base* 类型

底层步骤：
  1. 通过 vptr 找到虚析构函数
     → vtable → &Derived::~Derived
  2. 调用 Derived::~Derived()
     → 析构 Derived 的成员
     → vptr 设回 &Base::vtable
  3. 调用 Base::~Base()
     → 析构 Base 的成员
  4. operator delete(p)               → 释放堆内存

Q24：sizeof 相关的面试陷阱集合

// 空类
class Empty {};
sizeof(Empty);                    // 1（保证唯一地址）

// 含虚函数的空类
class VEmpty { virtual void f(); };
sizeof(VEmpty);                   // 8（一个 vptr）

// 多重继承
class A { virtual void f(); };
class B { virtual void g(); };
class C : public A, public B {};
sizeof(C);                        // 16（两个 vptr）

// 虚继承
class D : virtual public A {};
sizeof(D);                        // 16 或更大（vptr + 虚基类偏移）

// 数组
int arr[10];
sizeof(arr);                      // 40（10 × 4）

// 指针
sizeof(int*);                     // 8（64 位系统）
sizeof(void*);                    // 8

// 引用
int x;
sizeof(int&);                     // 4（等价于 sizeof(int)）

// 函数参数中的数组退化为指针
void func(int arr[]) {
    sizeof(arr);                  // 8！不是数组大小！是指针大小
}

Q25：面试口诀速查

虚函数：
  "每个类一份表，每个对象一个指针"
  "构造从基到派，析构从派到基"
  "构造中调虚不多态"

异常：
  "不抛就免费，抛了就很贵"
  "RAII 是异常安全的基石"
  "析构绝不抛异常"

值类别：
  "左值有地址，右值是临时，将亡值要搬家"
  "move 不移动，只是类型转换"
  "forward 保原样"

编译链接：
  "预处理展开，编译生汇编，汇编出目标，链接成可执行"
  "静态链接复制，动态链接引用"
  "模板放头文件，否则链接找不到"

内存：
  "栈向下长，堆向上长"
  "大成员放前面，减少 padding"
  "空类占 1 字节，虚类占 8 字节"

---

本系列相关文章：

• 现代 C++ 面试题 —— 语言特性与新标准
• 锁、并发与内存模型面试题 —— 多线程
• 数据结构与算法面试题 —— 通用算法体系
• 操作系统面试题 —— 进程/线程/内存/IO