feat: updates the progresses

Author: Charliechen114514

drafts/Content-Table-Draft.md

@@ -38,59 +38,40 @@
 
 - [x] 4.1 构造函数优化：初始化列表与成员初始化
 - [x] 4.2 移动语义（Move Semantics）在嵌入式中的应用
-- [ ] 4.3 RVO与NRVO（返回值优化）
-- [ ] 4.4 空基类优化（EBO）
-- [ ] 4.5 对象大小与内存对齐
-- [ ] 4.6 trivial类型与标准布局类型
-- [ ] 4.7 聚合初始化与designated initializers（C++20）
-
-#### 第4章 模板与泛型编程
-
-- 5.1 函数模板与类模板基础
-- 5.2 模板特化与偏特化
-- 5.3 SFINAE与编译期类型选择
-- 5.4 if constexpr（C++17）：编译期分支
-- 5.5 概念（Concepts，C++20）：约束模板参数
-- 5.6 模板实例化控制：显式实例化与extern template
-- 5.7 零成本策略模式实现
+- [x] 4.3 RVO与NRVO（返回值优化）
+- [x] 4.4 空基类优化（EBO）
+- [x] 4.5 对象大小与内存对齐，trivial类型与标准布局类型，聚合初始化与designated initializers（C++20）
 
 #### 第5章 编译期编程技术
 
-- `constexpr`（C++11/14/17/20）与设计技巧：常量表达式计算、lookup tables、编译期字符串处理
-- `consteval`、`constinit`（C++20）
-- 类型萃取（Type Traits）
-- 编译期查找表生成
-- 编译期状态机设计
-- 编译期单位转换与物理量计算
-- 模板元编程（TMP）基础与实用模式（编译期映射、选择实现）
-- `static_assert`、SFINAE、`if constexpr`
-- 练习：实现一个编译期 CRC 表或小型 FSM，并比较运行时 vs 编译期实现差异
+- [x] `constexpr`（C++11/14/17/20）与设计技巧：常量表达式计算、lookup tables、编译期字符串处理
+- [x] `consteval`、`constinit`（C++20）
+- [x] 编译期应用——查找表生成，状态机设计与单位转换与物理量计算
+- [x] `if constexpr`
 
 ------
 
 ## **第三部分：内存管理与资源控制**
 
 #### 第6章 避免动态内存分配
 
-- 7.1 动态内存的代价：碎片化与不确定性（内存布局（静态、堆、栈）、碎片化与内存对齐）
-- 7.2 静态存储与栈上分配策略
-- 7.3 对象池（Object Pool）模式
-- 7.4 固定池 / slab / arena 分配器实现与比较
-- 7.5 禁用 heap 或限制 heap 时的替代策略：放置new（Placement New）的使用
-- 7.6 std::array vs C数组，你们知道嘛？
-- 7.7 无堆容器设计
+- [x] 7.1 动态内存的代价：碎片化与不确定性（内存布局（静态、堆、栈）、碎片化与内存对齐）
+- [x] 7.2 静态存储与栈上分配策略
+- [x] 7.3 对象池（Object Pool）模式
+- [x] 7.4 固定池 / slab / arena 分配器实现与比较
+- [x] 7.5 禁用 heap 或限制 heap 时的替代策略：放置new（Placement New）的使用
+- [x] 7.6 std::array vs C数组，你们知道嘛？
 
 #### 第7章 智能指针与RAII
 
-- RAII 在驱动/外设管理中的应用（GPIO、SPI、DMA、文件句柄）
-- `unique_ptr`、`shared_ptr` 的嵌入式取舍（内存成本、控制周期）
-- intrusive 智能指针与引用计数（非堆实现）
-- 8.2 std::unique_ptr：零开销的独占所有权
-- 8.3 std::shared_ptr在嵌入式中的考虑
-- 8.4 自定义删除器（Custom Deleter）
-- 8.5 引用计数的实现与性能
-- 8.6 资源句柄封装：GPIO、外设、文件描述符
-- 8.7 作用域守卫（Scope Guard）模式
+- [x] RAII 在驱动/外设管理中的应用（GPIO、SPI、DMA、文件句柄）
+- [x] `unique_ptr`、`shared_ptr` 的嵌入式取舍（内存成本、控制周期）
+- [x] intrusive 智能指针与引用计数（非堆实现）
+- [x] 8.2 std::unique_ptr：零开销的独占所有权
+- [x] 8.3 std::shared_ptr在嵌入式中的考虑
+- [x] 8.4 自定义删除器（Custom Deleter）
+- [x] 8.5 引用计数的实现与性能
+- [ ] 8.6 作用域守卫（Scope Guard）模式
 
 #### 第8章 容器与数据结构
 
@@ -160,6 +141,16 @@
 - RTTI 的成本与替代（静态多态、CRTP）
 - 练习：把一个使用异常的库改造为返回 `Result<T, E>` 的风格
 
+#### 第4章 模板与泛型编程
+
+- 5.1 函数模板与类模板基础
+- 5.2 模板特化与偏特化
+- 5.3 SFINAE与编译期类型选择
+- 5.4 if constexpr（C++17）：编译期分支
+- 5.5 概念（Concepts，C++20）：约束模板参数
+- 5.6 模板实例化控制：显式实例化与extern template
+- 5.7 零成本策略模式实现
+
 ------
 
 #### 第15章 高性能数据结构与算法（嵌入式角度）

tutorial/核心：现代嵌入式C++教程/Chapter3/3 RVO, NRVO.md

@@ -0,0 +1,101 @@
+# RVO 与 NRVO：C++ 返回值优化
+
+我相信绝大多数人在写C和老C++的时候，不会喜欢返回大结构体，因为这一定会触发一次对象拷贝，对不对？但是从C++11开始，有一种看不见却又非常实在的性能魔法——返回值优化（RVO, Return Value Optimization）和命名返回值优化（NRVO, Named RVO）悄然登场。它们悄无声息地消灭了很多本可以发生的拷贝（甚至移动），让你写“自然、直观”的代码而不用为性能担忧。今天把这事讲清楚：为什么会发生，什么时候发生，哪些写法能触发（或阻止）它，最后给出实用建议，能直接贴上博客去。
+
+------
+
+## 试一试比较流行的TL;DR
+
+- **RVO/NRVO 能避免拷贝/移动构造，直接在调用者的空间构造返回对象**，因此性能好。
+- **C++17 对某类返回做了“保证消除”**（即在某些返回情形下拷贝/移动被标准强制省略）。
+- **不要为了“显式移动”而写 `return std::move(x);`** —— 这通常会阻止 NRVO，反而更慢。
+- 想得到最稳妥的性能：**写自然、直观的返回本地对象的代码，信任编译器／标准**。需要针对性优化时再测和调。
+
+------
+
+## RVO、NRVO 究竟是什么
+
+想象函数要返回一个大对象：如果按字面实现，函数会在内部构造一个临时对象，然后拷贝（或移动）到调用点；拷贝很贵。RVO/NRVO 的核心思路是，把“要返回的对象”**直接在调用者提供的内存里构造**，函数体内构造的就是最终对象——没有中间拷贝，也没有额外分配。RVO（匿名返回值优化）指的是直接返回一个临时表达式；NRVO（命名返回值优化）指的是返回函数内部的**命名局部变量**时进行的优化。
+
+举个直观的对比：
+
+```cpp
+// 假设 MyBigType 的拷贝/移动很贵
+MyBigType make1() {
+    MyBigType tmp(...); // 命名局部变量 tmp
+    // 若触发 NRVO，tmp 会在调用者的空间中直接构造
+    return tmp;         // NRVO 有机会发生
+}
+
+MyBigType make2() {
+    return MyBigType(...); // 直接返回临时，RVO 有机会发生
+}
+```
+
+在没有任何优化时，`make1` 可能会发生一次拷贝（或移动），而有了 NRVO/RVO，拷贝/移动被省了。
+
+------
+
+## C++17 后的变化
+
+在 C++17 之前，RVO/NRVO 是一种“允许但非必需”的优化：编译器通常会做，但标准并不强制。**从 C++17 起，标准在若干情况下要求进行拷贝消除**（例如返回 prvalue 时会被保证省略拷贝/移动）。这意味着，有些写法不再依赖编译器幸运与否：符合标准保证消除（guaranteed elision）的情形，编译器必须直接在目标处构造对象。
+
+所以：在现代 C++（>= C++17）中，你能更放心地写 `return MyType(...);` 而不担心隐藏的拷贝成本。
+
+------
+
+## 哪些情形会阻止 NRVO / RVO？——常见踩坑
+
+1. **多处 return 返回不同的局部变量**：如果函数有多个分支，每个分支返回不同的局部命名对象，编译器可能无法把它们都放在同一个目标空间，从而无法做 NRVO。
+2. **返回函数参数或引用**：NRVO 只针对函数内部要返回的对象，不会把函数参数“移动”成返回对象的目标。
+3. **对返回的局部变量做 `std::move`**：`return std::move(x);` 会把 x 视为右值，从而抑制 NRVO（因为你显式表明想移动），编译器会选择移动而不是消除拷贝；通常这是退步。
+4. **异常控制流和复杂语义**：在某些复杂控制流或异常相关的语义下，编译器可能无法模板化地保证消除（但在 C++17 的一些常见场景，这点已被标准覆盖）。
+5. **编译器被禁用消除的标志**：很多编译器有关闭拷贝消除的开关（如 GCC 的 `-fno-elide-constructors`），用于测试行为；不要在发布构建中打开这个。
+
+举个阻止 NRVO 的小例子：
+
+```cpp
+MyBigType bad(bool flag) {
+    MyBigType a(...);
+    MyBigType b(...);
+    if (flag) return a; // 可能无法 NRVO，因为另一分支返回不同命名对象
+    else     return b;
+}
+```
+
+相比之下，下面更有利于 NRVO（或至少更简单）：
+
+```cpp
+MyBigType good(bool flag) {
+    if (flag) return MyBigType(...); // RVO 或者 C++17 保证消除
+    else     return MyBigType(...);
+}
+```
+
+------
+
+## `std::move` 的误用
+
+很多人习惯在返回局部变量时写 `return std::move(x);`，自以为可以强制移动从而更快。实际上：
+
+- `return x;` —— 编译器**可能**做 NRVO（直接消除），也可能做移动构造（如果 NRVO 不可行）。
+- `return std::move(x);` —— 明确禁用了 NRVO 的机会（把 x 当作右值），编译器不得不执行移动构造。移动也有代价（尤其是当移动也要释放老资源、执行内存操作时）。因此，**不要用 `std::move` 优化 return 本地变量**，除非你对编译器行为和性能有充分测量和特殊原因。
+
+简言之：`return std::move(x);` 往往是个性能反例而不是优化。
+
+------
+
+## 实用建议（写代码的姿势）
+
+- **写直观的代码**：把函数实现写成自然的形式：构造局部对象并 `return` 它，或者直接 `return Type(args...)`。现代编译器和标准会替你把代价抹掉。
+- **别写 `return std::move(local);`** 来“强制”移动——这是反优化。
+- **在性能敏感处用基准（benchmark）说话**：不同平台、不同编译器、不同类型（移动开销 vs 拷贝开销）差别很大，遇到疑问就测。
+- **若必须避免拷贝，考虑传出参数或 emplace 风格**：比如 `void fill_into(MyBigType &out);` 或者 `MyBigType::create(..., std::in_place_args)`，但这应作为必要时的方案，不是常态。
+- **注意异常安全与语义清晰**：为了讨好 RVO 而写晦涩代码不可取，优先保证正确与易读。性能问题可在热点处剖析。
+
+------
+
+## 小结
+
+RVO 和 NRVO 是 C++ 给我们的一份免费礼物：在不牺牲可读性的前提下，编译器能把许多看似昂贵的返回开销抹掉。自 C++17 起，某些返回情形的消除变成了语言保证，这让我们写返回值风格的接口更加安心。日常开发里，遵循“写出自然、清晰的返回语义，信任编译器”的原则；当性能成问题时，用测量代替猜测，再针对性地调整实现。
+

tutorial/核心：现代嵌入式C++教程/Chapter3/4 空基类优化（EBO）.md

@@ -0,0 +1,86 @@
+# 空基类优化（EBO）：C++ 的瘦身技巧
+
+有一种低调而高效的内存优化，总在你看不到的地方帮你省下一点字节——**空基类优化（Empty Base Optimization, EBO）**。写库时常会用到空类作为“策略/标签/无状态的行为对象”，EBO 能把这些没有状态的基类挤出对象布局，节省空间、提升局部性。
+
+------
+
+## 还是试试TL;DR
+
+- **EBO 允许编译器把空的基类子对象的存储省掉（即不占额外字节），从而减小派生类的 sizeof。** 
+- **空成员变量默认不能被 EBO 压缩，但 C++20 引入的 `[[no_unique_address]]` 可以对成员实现类似的压缩效果。**
+- **不要依赖对象地址唯一性去识别空子对象——地址可能相同（这是被允许的优化副作用），对地址的假设会导致 bug。** 
+- 实战：库实现常用“继承空策略类”或“compressed pair”技巧；C++20 让事情更干净，但了解传统 EBO 仍然很有用。
+
+------
+
+## 概念从生活化的比喻说起
+
+想象一个容器对象里有两个成员：一个是真正装东西的仓库（比如 `int`、指针），另一个是空的“标签”——仅代表行为，没有数据。直觉上你可能会给每个成员都分配空间，但语言标准允许编译器把“空标签”这个基类子对象放到不占额外空间的位置（比如复用派生对象的首字节）。这样派生对象整体更小，缓存更友好——这就是 EBO 的核心。
+
+标准把“最派生对象必须有非零大小”的要求施加在最派生对象上，但**基类子对象不受此限制**，编译器可以把空基类子对象大小视为 0（即不占额外字节）。这正是 EBO 的法理学来源。
+
+------
+
+## 简单示例
+
+```cpp
+struct Empty {}; // 空类
+
+struct A {
+    Empty e;     // 成员，通常会占 1 字节
+    int x;
+};
+
+struct B : Empty { // 继承 Empty —— EBO 有机会发生
+    int x;
+};
+
+static_assert(sizeof(A) >= sizeof(int) + 1);
+static_assert(sizeof(B) == sizeof(int)); // 在支持 EBO 的编译器上通常成立
+```
+
+在上面例子中，`A` 中的 `Empty e` 是数据成员，按语言规则它需要占非零字节（以保证数组等语义）；而 `B` 把 `Empty` 作为基类，编译器可以把它“压进”`B` 的布局中，从而 `sizeof(B)` 通常等于 `sizeof(int)`（不同编译器/ABI 可能细节不同）。
+
+------
+
+## 为什么 STL/库里常看到“继承空类”的套路？
+
+标准库里，像分配器（allocator）、比较器（comparator）、删除器（deleter）等类型往往是无状态的空类。如果把它们作为成员，会浪费空间；把它们作为基类（通常是**私有继承**）可以启用 EBO，节省对象体积。很多实现把指针+空删除器这种情况包装成“compressed pair”或类似工具，以实现最小化的对象大小。微软的 STL 博客和其他实现说明了这种做法的普遍性。
+
+------
+
+## C++20：`[[no_unique_address]]` 把“空成员优化”变得正式且安全
+
+传统 EBO 只能通过继承实现（成员无法被压缩）。C++20 引入的 `[[no_unique_address]]` 属性允许**成员**也能被允许与其它子对象共享地址（即允许零大小语义），从而用成员语法就能达到类似 EBO 的效果，代码更直观、语义更清晰。例如：
+
+```cpp
+struct Empty {};
+struct Holder {
+    [[no_unique_address]] Empty e; // 现在可以和其它成员共享地址
+    int x;
+};
+```
+
+这在实现上比私有继承更好看，也避免了继承带来的潜在接口暴露。cppreference 和一些实现文章对 `[[no_unique_address]]` 的语义与限制有总结，强烈建议在能用 C++20 的地方优先采用。
+
+------
+
+## 常见误解与踩坑（务必注意）
+
+- **“空类子对象一定没有地址”——错。** 标准允许基类子对象与最派生对象共享起始地址；这会导致基类子对象的地址可能与其它子对象（或对象整体）相同。不要写依赖子对象地址唯一性的代码。
+- **`std::pair` 为何不能直接利用 EBO？** 因为 `std::pair` 把 `first` 和 `second` 作为**成员**而不是空基类，因此传统 EBO 无法用于成员（除非使用 `[[no_unique_address]]` 或把实现改成 compressed-pair 风格）。这也是为啥有 “compressed pair” 之类的内部实现技巧。
+- **多个空基类有时会互相影响**：若你从多个空类型继承，编译器会尝试为它们做 EBO，但在某些情况下（比如重复的基类类型、ABI 或嵌套模板导致的类型相同）会限制优化。常见的做法是让每个空基类的类型对编译器来说“独一无二”（例如通过模板参数化）以确保压缩生效。有人把这个问题称为“需要使基类类型分别化”。
+
+------
+
+## 实战建议
+
+1. **默认不用过早优化**：把策略类写成空类、用成员或继承都行；可读性优先。
+2. **若需要最小内存或实现库（如智能指针、容器），优先考虑 `[[no_unique_address]]`（C++20）或受控的私有继承 EBO 技巧。** C++20 能让代码更直观。
+3. **别依赖对象或子对象地址唯一性**：在写调试、序列化或比较逻辑时，避免用地址来区分空子对象。地址可能会相同，标准允许这种重用。
+
+------
+
+## 小结
+
+EBO 是 C++ 里一门“看得见效果却不显山露水”的微优化：让空策略类不再浪费字节。历史上我们用私有继承实现 EBO，现代 C++（C++20）通过 `[[no_unique_address]]` 让空成员也能被压缩，代码更直观更安全。实际工程里优先写清晰可维护的代码：当对象大小敏感时，再用 EBO / `[[no_unique_address]]` / compressed-pair 等技巧去手工优化，并在目标编译器上验证行为。