【C++第二十三章】C++11

前言 🚀

C++11 常被称为现代 C++ 的起点。它不是一次零碎的小修小补，而是一次真正改变编程方式的大版本更新：从统一初始化，到 auto / decltype 的类型推导；从右值引用、移动语义，到完美转发；再到 lambda、可变参数模板、function、bind 等工具，C++ 从这之后开始更强调表达能力、泛型能力和性能优化并存。

很多人在学习 C++11 时，会把这些特性拆成一堆分散知识点去背：{} 是列表初始化，&& 是右值引用，lambda 是匿名函数，function 是包装器......这样记当然能应付基础题，但一到容器插入优化、泛型接口设计、回调封装或者参数转发这些真实场景时，就很容易感觉"每个点都见过，但连不起来"。

真正更好的理解方式，是把它们放回同一条主线里：C++11 在解决的，是代码写法更统一、类型推导更自然、对象传递更高效、泛型接口更灵活、可调用对象更容易组织。 顺着这条线再看各个特性，逻辑会清楚很多。

一. `C++11` 到底带来了什么变化 🧠

在 C++98/03 时代，语言已经足够强大，但很多地方写起来依然比较笨重：初始化形式不统一、模板接口不够灵活、容器插入容易产生多余拷贝、泛型代码想保留参数属性也很麻烦。

C++11 之后，语言层和标准库层都发生了明显变化，最核心的几类改动可以概括成：

统一初始化方式
更自然的类型推导
移动语义与右值引用
可变参数模板
lambda 表达式
更通用的可调用对象包装与绑定
标准库容器与接口的同步升级

也就是说，C++11 并不是单独加了几个语法糖，而是把"写法、类型、对象生命周期、泛型接口、库设计"这一整套体系往现代风格推进了一步。

二. 列表初始化：为什么 `{}`

会成为更统一的初始化方式 🔍

C++11 最直观的变化之一，就是大量场景都可以使用花括号初始化，也就是常说的列表初始化。

2.1 它统一了原本分裂的初始化写法

在旧风格里，内置类型、对象、数组、容器，各自可能有不同初始化形式；而 C++11 试图用 {}

尽量统一这些入口：

cpp 复制代码

int i = 0;
int j{0};

pair<int, int> p{1, 2};
vector<int> v{1, 2, 3, 4};
map<string, string> dict{{"insert", "插入"}, {"left", "左边"}};

这样做的好处不是"写法更酷"，而是初始化语义更集中、更一致，代码可读性会更好。

2.2 为什么 `vector` 和 `list` 能直接用 `{}` 初始化

这背后依赖的是 std::initializer_list。标准库容器提供了接收 initializer_list 的构造函数，因此花括号里的多个元素，会被组织成一个初始化列表对象，再交给容器构造。

cpp 复制代码

vector<int> v1 = {1, 2, 3, 4};
list<int> lt = {10, 20, 30};

2.3 `initializer_list` 本质上是什么

它可以理解成一个轻量只读视图，内部通常只需要保存：

起始位置
结束位置（或长度信息）

因此它天然支持遍历，而不负责元素所有权管理。

cpp 复制代码

initializer_list<int> il = {10, 20, 30};
for (auto e : il)
{
    cout << e << " ";
}

2.4 自己实现的容器为什么默认不支持这种初始化

因为花括号初始化不是"自动万能魔法"，而是因为容器提供了对应构造函数。若自己写一个 vector，默认并不会自动识别这种形式，只有补上类似下面的构造接口，才真正具备这个能力：

cpp 复制代码

vector(initializer_list<T> lt)
{
    reserve(lt.size());
    for (const auto& e : lt)
    {
        push_back(e);
    }
}

2.5 `map` 为什么也能这么写

因为 map 的值类型本来就是 pair<const K, V>。当写成：

cpp 复制代码

map<string, string> dict{
    {"insert", "插入"},
    {"left", "左边"}
};

每个花括号对都可以隐式转换成对应的 pair，再由 initializer_list 构造整体容器。

💡 避坑指南：
{} 不是"任何类型都自动支持"的语法特权。

真正生效，依赖的是类型本身有没有提供匹配的构造语义，尤其是 initializer_list 构造。

三. `auto` 与 `decltype`：类型推导为什么会变得更自然 🧩

模板和泛型代码一旦多起来，显式写出复杂类型会非常累，尤其是迭代器、函数返回值、表达式结果类型。C++11 在这一块给出了两套非常实用的工具：auto 和 decltype。

3.1 `auto` 解决的是"初始化时类型太啰嗦"

cpp 复制代码

vector<int> v{1, 2, 3, 4};

for (auto it = v.begin(); it != v.end(); ++it)
{
    cout << *it << " ";
}

这里 auto 让代码不用显式写一长串迭代器类型，尤其对模板容器和复杂类型非常友好。

3.2 `auto` 最常见的价值

配合范围 for
接收复杂返回类型
简化局部变量声明
写泛型代码时减少样板代码

3.3 `decltype` 解决的是"我想拿到某个表达式的类型"

auto 依赖初始化推导，而 decltype 则直接根据一个表达式推导类型本身。

cpp 复制代码

int i = 1;
double d = 2.2;

auto ret = i * d;      // ret 是 double
decltype(ret) x = 3.14;

3.4 它为什么比 `auto` 更适合类型声明场景

因为 decltype 得到的是一个类型结果，所以它可以继续用于：

定义对象
模板实参
返回值声明
类型别名等场景

cpp 复制代码

vector<decltype(ret)> v;

3.5 二者该怎么分工理解

工具	主要用途
`auto`	让变量声明更简洁
`decltype`	从表达式中提取类型本身

四. 右值引用与移动语义：`C++11` 最核心的性能升级 ⚠️

如果说 C++11 里最值得真正吃透的一块，那一定是右值引用 + 移动语义。因为它直接影响对象传递、容器扩容、返回值优化、插入性能等大量核心行为。

4.1 左值和右值到底怎么区分

最稳定的判断方式不是"写在左边还是右边"，而是看能不能稳定地取地址、能不能作为持久对象身份存在。

左值：通常有名字、可取地址、生命周期相对稳定
右值：通常是临时结果、字面值、表达式结果、将要销毁的对象

例如：

cpp 复制代码

int a = 10;      // a 是左值
10;              // 字面值是右值
a + 1;           // 表达式结果是右值

4.2 为什么要引入右值引用

因为在旧语义下，很多临时对象虽然马上就要被销毁，但在传递过程中依然只能按"可拷贝对象"处理，这会带来大量不必要的深拷贝。

C++11 引入右值引用，本质上是在告诉编译器和程序员：

这个对象是"将亡值"，可以安全地把内部资源转移走，而不是再做一次昂贵拷贝。

4.3 移动构造为什么能快很多

假设一个字符串内部维护一块堆空间。若用拷贝构造，就要重新申请空间、拷贝字符；而移动构造可以直接"接管"原对象持有的资源。

cpp 复制代码

class String
{
public:
    String(String&& s)
    {
        swap(s);
    }
};

这种思路的本质不是复制数据，而是交换资源所有权。

4.4 返回值为什么因此受益特别大

函数返回局部对象时，旧时代往往担心"返回后对象销毁，引用失效，拷贝很重"。而有了移动语义后，局部对象在生成返回值时可以被识别为将亡值，从而触发移动构造或进一步优化。

cpp 复制代码

string to_string(int x)
{
    string ret;
    // ...
    return ret;
}

这里的 ret 在离开函数前，本来就是"马上就没用了"的对象，因此特别适合被移动出去。

4.5 `move` 到底做了什么

std::move 不会真的移动任何资源，它做的事情只有一个：

把一个表达式强制转换成右值语义。

cpp 复制代码

String s1("hello");
String s2 = std::move(s1);

真正发生资源转移的是后续匹配到的移动构造 / 移动赋值，而不是 move 本身。

4.6 `move` 之后原对象还能不能用

可以继续析构、赋新值、重新初始化，但不应该再依赖其原有值。因为资源很可能已经被转移走了。

💡 避坑指南：
move 后的对象不是"已经被销毁"，而是"仍然有效，但值处于未指定的可析构状态"。

最安全的做法，是把它当成一个可重新赋值、但不应继续读取业务语义的对象。

五. 右值引用变量本身为什么又成了左值 🔍

这是学习右值引用时最容易拧巴的一点。

cpp 复制代码

void func(String&& x)
{
    // 这里的 x 虽然类型是 String&&
    // 但表达式 x 本身是左值
}

5.1 原因并不神秘

因为只要一个对象有名字，它在表达式里就有稳定身份，于是它就是左值。否则你根本没法对它继续操作、继续修改，也没法在函数体里完成真正的资源转移。

5.2 那怎么再次把它当右值用

加 std::move：

cpp 复制代码

void push_back(T&& x)
{
    insert(end(), std::move(x));
}

也就是说：

参数类型可以是右值引用
但函数体里这个有名变量本身仍是左值
真要继续往下传右值语义，就必须显式 move

六. 万能引用、引用折叠与完美转发：泛型接口真正困难的地方 🧱

仅有右值引用还不够，因为模板场景下，我们常常并不希望"强行把所有参数都变成右值"，而是希望：

传进来是左值，就继续按左值传；传进来是右值，就继续按右值传。

6.1 万能引用出现在哪里

当模板参数推导和 T&& 同时出现时：

cpp 复制代码

template<class T>
void PerfectForward(T&& t)
{
    // ...
}

这里的 T&& 不是普通意义的右值引用，而是转发引用（常被口语化称为万能引用）。

6.2 为什么它既能接左值也能接右值

因为模板推导会结合引用折叠规则：

T& & 折叠成 T&
T& && 折叠成 T&
T&& & 折叠成 T&
T&& && 折叠成 T&&

本质规律就一句话：

只要有左值引用参与，最后结果通常折叠成左值引用。

6.3 为什么直接传 `t` 往往全变成左值了

cpp 复制代码

template<class T>
void PerfectForward(T&& t)
{
    Fun(t);  // t 有名字，所以这里是左值
}

这就又回到了前一节那个问题：有名变量就是左值。

6.4 正确做法：`forward`

cpp 复制代码

template<class T>
void PerfectForward(T&& t)
{
    Fun(std::forward<T>(t));
}

forward 的价值就在于：根据模板参数 T 恢复参数最初传入时的值类别。

原来传左值，继续保持左值
原来传右值，继续保持右值

这才叫完美转发。

💡 避坑指南：
std::move 是无条件右值化，std::forward 是按原始属性有条件转发。

模板转发场景里，绝大多数时候应该优先考虑 forward，而不是一股脑 move。

七. 默认成员函数在 `C++11` 里为什么更复杂了 🧩

一旦引入移动构造和移动赋值，类的默认成员函数规则就不可能再像旧时代那样简单了。

7.1 `C++11` 之后更值得关注的是"八个默认成员函数"

常见需要统一考虑的包括：

默认构造
析构
拷贝构造
拷贝赋值
取地址重载
const 取地址重载
移动构造
移动赋值

7.2 为什么编译器有时不会生成移动构造 / 移动赋值

因为一旦你自己写了析构、拷贝构造、拷贝赋值中的某些成员，编译器通常会认为：这个类可能在进行特殊资源管理，例如深拷贝、引用计数、句柄管理等。

在这种情况下，自动给你补一个"按成员搬过去"的移动操作，很可能并不安全，所以它会变得更保守。

7.3 `= default` 和 `= delete` 的作用

若你明确知道自己想要什么，可以显式告诉编译器：

cpp 复制代码

Person(const Person&) = default;
Person(Person&&) = delete;

它们分别表示：

= default：强制使用默认生成版本
= delete：显式禁止这个函数被调用或生成

7.4 `final` 和 `override`

这两个也属于 C++11 引入的非常实用的类设计工具：

override：显式标记"我要重写父类虚函数"，可帮助编译器检查签名是否真的匹配
final：阻止继续继承，或阻止某个虚函数再被重写

八. `emplace` 和 `push_back`：看起来像一个功能，底层其实不一样 💻

C++11 标准库大量补充了右值重载和 emplace 系列接口，这些改动和移动语义是强关联的。

8.1 `push_back` 的本质

push_back 接收的是一个"已经存在的对象"：

cpp 复制代码

list<string> lt;
string s = "hello";

lt.push_back(s);           // 拷贝
lt.push_back(std::move(s)); // 移动

8.2 `emplace_back` 的本质

emplace_back 接收的是构造参数，它会把这些参数继续往下传，直接在结点或容器内部构造对象。

cpp 复制代码

list<string> lt;
lt.emplace_back("hello");

8.3 为什么它有时更高效

若传入 "sss" 这样的 const char*：

push_back("sss") 往往要先构造临时 string，再插入
emplace_back("sss") 则可能直接在容器内部构造 string

这就减少了中间对象的构造与搬运。

8.4 多参数场景下优势更明显

对于存储 pair<string, int> 的容器：

cpp 复制代码

list<pair<string, int>> lt;

lt.push_back(make_pair("1111", 1));
lt.emplace_back("1111", 1);

后者可以直接把参数透传到底层对象构造过程，通常更自然。

8.5 为什么很多时候提升并没有想象中夸张

因为 C++11 之后，移动构造本身已经把中间对象成本压得很低了。所以在很多普通对象场景里，emplace 的优势是存在的，但未必是数量级上的飞跃。

💡 避坑指南：
emplace 并不总是"绝对更快"。

当对象本身已经具备高效移动构造时，push_back(std::move(x)) 和 emplace_back(...) 的差距可能没有想象中大。

九. 可变参数模板：为什么模板终于能优雅接收任意参数个数 🗺️

在 C++11 之前，想写"任意参数个数"的泛型接口非常麻烦，很多库只能用宏、重载展开或 printf 风格变参硬撑。C++11 的可变参数模板，彻底改善了这个问题。

9.1 参数包是什么

cpp 复制代码

template<class... Args>
void ShowList(Args... args)
{
    cout << sizeof...(args) << endl;
}

这里有两层参数包：

Args...：模板参数包
args...：函数形参包

它们的意义是：可以接收任意个、任意类型的参数。

9.2 为什么不能直接像数组那样下标访问

因为参数包不是数组，也不是容器，它只是编译期的一组独立参数集合，没有统一下标语义。

9.3 早期常见展开方式：递归展开

cpp 复制代码

void _ShowList()
{
    cout << endl;
}

template<class T, class... Args>
void _ShowList(const T& value, Args... args)
{
    cout << value << " ";
    _ShowList(args...);
}

template<class... Args>
void ShowList(Args... args)
{
    _ShowList(args...);
}

这种写法本质上依赖编译器在编译期不断把"第一个参数 + 剩余参数包"拆开，直到参数包为空。

9.4 另一种展开技巧：借助初始化列表

cpp 复制代码

template<class T>
int PrintArg(T t)
{
    cout << t << " ";
    return 0;
}

template<class... Args>
void ShowList(Args... args)
{
    int arr[] = { PrintArg(args)... };
    cout << endl;
}

这里利用了初始化列表必须确定长度、并对每个元素求值的特点，让参数包被逐个展开。

十. `lambda` 表达式：为什么它本质上还是仿函数 🔗

lambda 是 C++11 最受欢迎的特性之一，因为它极大改善了"临时可调用逻辑"的表达方式。

10.1 它的直观意义

cpp 复制代码

auto f = [](int x) -> int { return x * 2; };
cout << f(3) << endl;

看起来像匿名函数，但从语言底层实现看，它更像是一个匿名函数对象。

10.2 为什么说底层还是仿函数

因为编译器通常会为每个 lambda 生成一个独立类，这个类中重载了 operator()。也正因如此，不同 lambda 即使写法很像，本质上也是不同类型。

10.3 典型语法结构

cpp 复制代码

[capture-list](parameters) mutable -> return_type { statement; }

最重要的几个部分是：

捕获列表：决定外部变量如何进入 lambda
参数列表：和普通函数类似
mutable：允许修改按值捕获的副本
返回类型：可省略，由编译器推导
函数体：具体执行逻辑

10.4 为什么它能替代很多仿函数场景

例如排序时：

cpp 复制代码

sort(v.begin(), v.end(), [](const Goods& g1, const Goods& g2) {
    return g1._price < g2._price;
});

如果只为了这一处比较逻辑单独写一个仿函数类，显然更啰嗦。lambda 恰好让局部逻辑就地表达，代码可读性会高很多。

十一. 捕获列表：`lambda` 真正灵活的地方 ⚠️

lambda 和普通匿名函数最大的差别在于：它可以捕获外部作用域变量。

11.1 常见捕获方式

写法	含义
`[x]`	按值捕获 `x`
`[&x]`	按引用捕获 `x`
`[=]`	按值捕获所有可用变量
`[&]`	按引用捕获所有可用变量
`[=, &z]`	默认按值，但 `z` 按引用
`[&, x]`	默认按引用，但 `x` 按值

11.2 为什么按值捕获默认不能改

因为 lambda 的 operator() 默认是 const 成员函数，按值捕获得到的其实是内部成员副本。若想在函数体内修改它们，需要显式加 mutable。

cpp 复制代码

int x = 1;
auto f = [x]() mutable {
    x++;
};

11.3 为什么按引用捕获通常不用 `mutable`

因为这里改的不是 lambda 自己持有的值副本，而是外部对象本身，语义上和修改引用对象一致。

11.4 类成员为什么很多时候不用显式写 `this`

在类的成员函数里，lambda 若访问成员变量，编译器会帮助处理对当前对象的访问语义，因此很多场景写成 [=] 或 [&] 依然能自然使用成员变量。不过从可读性和明确性角度，是否显式写 this 仍值得根据团队风格决定。

💡 避坑指南：
不要随手用 [&] 把所有东西都引用捕获。

这样虽然省事，但容易把生命周期问题和副作用一起带进来，尤其是异步场景、延迟回调和容器存储场景。

十二. `function` 与 `bind`：可调用对象终于能被统一管理 🧩

函数指针、仿函数、lambda 都是可调用对象，但它们类型完全不同。C++11 提供了 std::function，让这些调用形式终于有了统一包装方式。

12.1 `function` 是什么

cpp 复制代码

function<int(int, int)> f;

它本质上是一个类模板，用签名来描述"这个可调用对象应该长什么样"：

返回值类型
参数列表类型

只要某个函数指针、仿函数、lambda 能匹配这个签名，就可以装进去。

12.2 它能统一包装哪些对象

普通函数
函数指针
仿函数对象
lambda
成员函数（配合对象或额外绑定）

12.3 一个典型价值：命令分发表

cpp 复制代码

map<string, function<void(int&, int&)>> cmdOP = {
    {"函数指针", swap_func},
    {"仿函数", Swap()},
    {"lambda", swaplambda}
};

这时候字符串 key 就像命令，value 是统一签名的可调用对象。调用时无需关心底层到底是函数、对象还是 lambda。

12.4 `bind` 解决了什么问题

bind 的作用主要有两个：

调整参数顺序
预绑定部分参数

例如：

cpp 复制代码

function<int(int, int)> f1 = bind(Sub, placeholders::_2, placeholders::_1);

这里就把原本 (a, b) 的顺序改成了 (b, a)。

再例如：

cpp 复制代码

function<int(int)> f2 = bind(Sub, 20, placeholders::_1);

这里把第一个参数固定成 20，后续只需要再传第二个参数。

12.5 为什么它适合做接口适配

在工程里，经常会遇到第三方库接口参数多、顺序不顺手、调用方只关心其中几个参数的情况。bind 可以提前把不变参数绑死，让外层使用更方便。

12.6 它的本质仍然是生成一个新的可调用对象

所以 bind(...) 的结果本身也可以继续装进 function，或者继续传递、存储、组合使用。

💡 避坑指南：
bind 不是不能用，但现代 C++ 里很多场景 lambda 更直观。

尤其是参数适配逻辑不复杂时，lambda 往往比多层 placeholders::_1/_2 更好读。

十三. 用一条主线把这些特性串起来 📌

如果把这一整章压缩成一条主线，可以这样理解：

{}
与 initializer_list 统一了初始化入口
auto 与 decltype 让类型表达更自然
右值引用与移动语义解决了临时对象传递成本高的问题
move、forward、引用折叠让模板接口能够保留对象原始属性
默认成员函数规则随之变复杂，但也更精细
emplace 把构造时机推进到容器内部
可变参数模板让任意参数个数的泛型接口成为可能
lambda 让局部可调用逻辑表达更简洁
function 和 bind 又把各种可调用对象统一到同一套调度方式中

所以它们不是零散补丁，而是一整套相互配合的现代化升级。

总结 📝

C++11 真正重要的，不是记住几个关键字，而是理解它把 C++ 往哪个方向推进了：写法更统一、类型表达更简洁、对象传递更高效、模板接口更灵活、可调用对象更容易组织。

围绕这条主线再回头看整章内容，很多原本看似分散的概念就会自然连起来：

列表初始化和 initializer_list 在统一初始化语义
auto / decltype 在降低类型表达成本
右值引用、移动构造、移动赋值在优化资源转移
move 和 forward 在区分"强制右值化"和"保持原始属性"
emplace 在减少中间对象
可变参数模板在提升泛型表达能力
lambda、function、bind 在统一可调用对象的组织方式

因此，学 C++11 最好的方式，不是把它当成几十个语法点去背，而是把它看成一次语言风格升级：从"能写出来"走向"写得更自然、更泛型、更高效"。

这也是后面继续学习 C++14/17/20、现代标准库、泛型库设计和高性能容器实现时，最重要的一层基础。

【C++第二十三章】C++11

前言 🚀

一. C++11 到底带来了什么变化 🧠

二. 列表初始化：为什么 {}

2.1 它统一了原本分裂的初始化写法

2.2 为什么 vector 和 list 能直接用 {} 初始化

2.3 initializer_list 本质上是什么

2.4 自己实现的容器为什么默认不支持这种初始化

2.5 map 为什么也能这么写

三. auto 与 decltype：类型推导为什么会变得更自然 🧩

3.1 auto 解决的是"初始化时类型太啰嗦"

3.2 auto 最常见的价值

3.3 decltype 解决的是"我想拿到某个表达式的类型"

3.4 它为什么比 auto 更适合类型声明场景

3.5 二者该怎么分工理解

四. 右值引用与移动语义：C++11 最核心的性能升级 ⚠️

4.1 左值和右值到底怎么区分

4.2 为什么要引入右值引用

4.3 移动构造为什么能快很多

4.4 返回值为什么因此受益特别大

4.5 move 到底做了什么

4.6 move 之后原对象还能不能用

五. 右值引用变量本身为什么又成了左值 🔍

5.1 原因并不神秘

5.2 那怎么再次把它当右值用

六. 万能引用、引用折叠与完美转发：泛型接口真正困难的地方 🧱

6.1 万能引用出现在哪里

6.2 为什么它既能接左值也能接右值

6.3 为什么直接传 t 往往全变成左值了

6.4 正确做法：forward

七. 默认成员函数在 C++11 里为什么更复杂了 🧩

7.1 C++11 之后更值得关注的是"八个默认成员函数"

7.2 为什么编译器有时不会生成移动构造 / 移动赋值

7.3 = default 和 = delete 的作用

7.4 final 和 override

八. emplace 和 push_back：看起来像一个功能，底层其实不一样 💻

8.1 push_back 的本质

8.2 emplace_back 的本质

8.3 为什么它有时更高效

8.4 多参数场景下优势更明显

8.5 为什么很多时候提升并没有想象中夸张

九. 可变参数模板：为什么模板终于能优雅接收任意参数个数 🗺️

9.1 参数包是什么

9.2 为什么不能直接像数组那样下标访问

9.3 早期常见展开方式：递归展开

9.4 另一种展开技巧：借助初始化列表

十. lambda 表达式：为什么它本质上还是仿函数 🔗

10.1 它的直观意义

10.2 为什么说底层还是仿函数

10.3 典型语法结构

10.4 为什么它能替代很多仿函数场景

十一. 捕获列表：lambda 真正灵活的地方 ⚠️

11.1 常见捕获方式

11.2 为什么按值捕获默认不能改

11.3 为什么按引用捕获通常不用 mutable

11.4 类成员为什么很多时候不用显式写 this

十二. function 与 bind：可调用对象终于能被统一管理 🧩

12.1 function 是什么

12.2 它能统一包装哪些对象

12.3 一个典型价值：命令分发表

12.4 bind 解决了什么问题

12.5 为什么它适合做接口适配

12.6 它的本质仍然是生成一个新的可调用对象

十三. 用一条主线把这些特性串起来 📌

总结 📝

一. `C++11` 到底带来了什么变化 🧠

二. 列表初始化：为什么 `{}`

2.2 为什么 `vector` 和 `list` 能直接用 `{}` 初始化

2.3 `initializer_list` 本质上是什么

2.5 `map` 为什么也能这么写

三. `auto` 与 `decltype`：类型推导为什么会变得更自然 🧩

3.1 `auto` 解决的是"初始化时类型太啰嗦"

3.2 `auto` 最常见的价值

3.3 `decltype` 解决的是"我想拿到某个表达式的类型"

3.4 它为什么比 `auto` 更适合类型声明场景

四. 右值引用与移动语义：`C++11` 最核心的性能升级 ⚠️

4.5 `move` 到底做了什么

4.6 `move` 之后原对象还能不能用

6.3 为什么直接传 `t` 往往全变成左值了

6.4 正确做法：`forward`

七. 默认成员函数在 `C++11` 里为什么更复杂了 🧩

7.1 `C++11` 之后更值得关注的是"八个默认成员函数"

7.3 `= default` 和 `= delete` 的作用

7.4 `final` 和 `override`

八. `emplace` 和 `push_back`：看起来像一个功能，底层其实不一样 💻

8.1 `push_back` 的本质

8.2 `emplace_back` 的本质

十. `lambda` 表达式：为什么它本质上还是仿函数 🔗

十一. 捕获列表：`lambda` 真正灵活的地方 ⚠️

11.3 为什么按引用捕获通常不用 `mutable`

11.4 类成员为什么很多时候不用显式写 `this`

十二. `function` 与 `bind`：可调用对象终于能被统一管理 🧩

12.1 `function` 是什么

12.4 `bind` 解决了什么问题