utto的学习屋 https://www.yyshow.xyz/ Recording Everything Wed, 22 Jul 2026 06:30:54 GMT https://validator.w3.org/feed/docs/rss2.html https://github.com/jpmonette/feed zh-CN All rights reserved 2026, utto <![CDATA[查找、排序与算法选择]]> https://www.yyshow.xyz/article/search-sort-algorithm-selection https://www.yyshow.xyz/article/search-sort-algorithm-selection Thu, 16 Jul 2026 00:00:00 GMT
本篇整理常见查找与排序算法，并从时间复杂度、空间开销和数据特征出发比较算法选择。

1. 查找算法

本章从「顺序查找」「二分查找」和「树表的查找」等方面说明查找算法。

1.1 顺序查找

查找过程为：从表中一端开始，依次比较表中元素和给定的目标值，如果元素值等于目标值，则查找成功。
时间复杂度：O(N)
空间复杂度：O(1)
如果数组无序且数组规模比较小，那么可以使用；如果规模很大，这个实现性能会很差

1.2 二分查找

二分查找也称为折半查找。使用二分查找的前提是数组元素必须是有序的。查找过程为：给定一个数组和一个目标值，从表的中间位置开始记录，如果目标值和中间元素相同，则查找成功；如果中间元素小于或大于目标值，则在比中间值大或小的那一半中查找。重复操作，直到查找成功。实现代码有两种写法，取决于给定的查找范围是左闭右闭还是左闭右开的。
时间复杂度：O(logN)
空间复杂度：O(1)
时间复杂度计算过程：
第一次比较，剩余规模 n/2
第二次比较，剩余规模 n/4
第三次比较，剩余规模 n/8
……
第 k 次比较，剩余规模
在最坏情况下，搜索区间只剩最后一个元素，所以我们的 k 满足；
所以 ，时间复杂度为

1.3 树表的查找

树表是利用树形结构组织的数据查找表，其目标是实现 级别的高效查找、插入和删除操作。
1.3.1 二叉排序树（BST）
又称为二叉查找树、二叉搜索树，是一种特殊的二叉树，满足以下基本特性：
  1. 左小右大：左边的节点小于中间的节点，中间的节点小于右边的节点
  1. 左右子树本身也分别是二叉排序树
  1. 中序遍历 BST 得到的序列是完全有序的
平均时间复杂度：O(log N)
最坏时间复杂度：O(N)
1.3.2 平衡二叉树（AVL）
是最早被发明的自平衡二叉树，严格满足以下特性：
  1. 任意节点左右子树的高度差的绝对值不超过 1
  1. 平衡因子 = 左子树高度 − 右子树高度
平均时间复杂度（查找、增删）：O(log N)
1.3.3 红黑树
红黑树是一种在平衡性和维护成本很好的折中的自平衡二叉排序树，每个节点被标记为黑色或红色。
满足以下规则：
  1. 根节点是黑色
  1. 叶子节点是黑色
  1. 如果一个节点是红色，那么它的两个子节点必须是黑色
  1. 从任意节点出发到其所有叶子节点上包含的黑色节点数量必须相等（黑色平衡）
平均时间复杂度（查找、增删）：O(log N)
1.3.4 B 树
B 树是一种多路搜索树，它的设计初衷是为了优化外部存储（如硬盘、SSD）的数据查找效率，与前面几种树的内存优化目标不同。
查找复杂度：。虽然理论上与 级别相似，但在外部存储中，M 越大，I／O 次数越少，实际性能越好。

2. 排序算法

本章从「直接插入排序」「二分插入排序」和「希尔排序」等方面说明排序算法。

2.1 直接插入排序

基本思想：类似于我们整理扑克牌，逐个顺序比较后插入。将数组分为已排序和未排序两个部分，第一个元素放入已排序部分，和未排序部分比较，直到排序完成。
时间复杂度：
  • 最好情况：O(n) - 数组已经有序
  • 最坏情况：O(n²) - 数组完全逆序
  • 平均情况：O(n²)
适用条件：当数据规模小、数据基本有序时可以使用。

2.2 二分插入排序

基本思想：二分插入排序是对直接插入排序的优化，在寻找插入位置时用二分查找代替顺序查找，减少了比较次数，但是移动次数不变。
时间复杂度：
  • 比较次数：O(n log n)
  • 移动次数：O(n²)
  • 总时间复杂度：O(n²)
适用条件：比较代价比较高的时候使用。

2.3 希尔排序

基本思想：也是对直接插入排序改进，又称为缩小增量排序，分组比较代替逐个比较。将原序列分成多个子序列进行插入排序，缩小间隔。重复以上过程，直到排序完成。
常见的增量序列：
  1. 希尔增量：n/2, n/4, …, 1
  1. Hibbard 增量：1, 3, 7, 15, …, 2^k-1
  1. Sedgewick 增量：1, 5, 19, 41, …
时间复杂度：
  • 最好情况：O(n log n)
  • 最坏情况：O(n²) - 使用希尔增量时
  • 平均情况：取决于增量序列
适用条件：中等规模数据时使用。

2.4 冒泡排序

基本思想：比较相邻元素，如果第一个元素比第二个元素大，则交换两个元素的位置。比较每一对•相邻元素，最后的元素一定是未排序中最大的。重复以上操作，直到排序完成。
时间复杂度：
  • 平均时间复杂度：O(N^2)
  • 交换次数：O(N^2)
  • 空间复杂度：O(1)
适用条件：小规模数据、数组基本有序、内存受限的情况。

2.5 选择排序

基本思想：在冒泡排序的基础上改进了交换次数，从第一个元素开始和后面的所有元素相比，比较出最小的元素，先记录下标，跟最后一个元素比较完之后再交换位置，得到最小元素。重复以上过程，直到排序完成。
时间复杂度：
  • 平均时间复杂度：
  • 交换次数：O(N)
  • 空间复杂度：O(1)
适用条件：小规模数据且比较代价高，内存受限的情况。

2.6 快速排序

基本思想：采用分治策略。选择一个基准元素，通过一趟排序将序列分隔成独立的两个部分，其中左边部分的所有元素比基准元素小，右边部分的所有元素都比基准元素大，然后再对这两个部分递归排序。
其中基准元素一般选：第一个元素、最后一个元素、中间元素。
时间复杂度
  • 平均时间复杂度：
  • 最坏时间复杂度：
  • 空间复杂度：
适用条件：当数据规模比较大、内存空间受限、数据分布随机时可以使用快排，但是如果数据分布本来就比较有序，选择最后一个元素作为基准时就容易将时间复杂度退化为。

2.7 堆排序

堆排序是一种树形选择排序，可以将待排序的数组看成是一颗完全二叉树的顺序存储结构。基本思想：排序规则是根节点小于或大于子节点，这样就可以将待排序序列构造成一个小顶堆或者是大顶堆。将堆顶元素和末尾元素交换，将剩余元素重新调整成堆，重复以上过程，直到堆中只剩一个元素。
堆的特性：
  1. 结构性：堆是一颗完全二叉树，底层节点从左到右填入
  1. 堆序性：
堆排序示意图
堆排序示意图
时间复杂度：（平均、最好、最坏）
空间复杂度：
适用条件：内存受限，且需要时间复杂度保证的场景。

2.8 归并排序

本节从「分治法」「单链表实现」和「数组实现」等方面说明归并排序。
2.8.1 分治法
分治通常包含三个步骤：
  1. 分解：将原问题拆成规模更小的子问题；
  1. 解决：递归或迭代处理子问题；
  1. 合并：组合子问题结果。
归并排序把“合并”作为核心步骤；快速排序则通过分区把元素放到基准值两侧，再分别处理两个子区间。
2.8.2 单链表实现
链表适合归并排序的原因：链表可以通过调整指针合并有序序列，不依赖随机访问。
  • 找中点可使用快慢指针；
  • 合并有序链表只需调整 next 指针；
  • 不依赖随机访问；
  • 时间复杂度稳定为 O(n log n)；
  • 可以保持稳定性。
递归实现：先使用快慢指针拆分链表，再递归排序并合并两个有序链表。
复杂度：
  • 时间复杂度：O(n log n)
  • 辅助空间复杂度：O(log n)，主要来自递归调用栈
边界条件中，下面这种写法：
在 head == nullptr 时会发生空指针解引用，应写成：
优先队列中转法：先把节点值放入小根堆，再按升序写回链表。
将节点值放入小根堆，再按顺序写回：
  • 时间复杂度：O(n log n)
  • 空间复杂度：O(n)
  • 实现简单；
  • 只改变值，不改变节点顺序。
如果题目要求真正重排节点、节点身份有意义，或节点除 val 外还含有相关数据，只交换/覆盖 val 可能不符合要求。
2.8.3 数组实现
复杂度：
  • 时间复杂度：O(n log n)
  • 空间复杂度：O(n)
  • 稳定：在相等时优先取左侧元素
常见应用：
  • 逆序对；
  • 外部排序；
  • 链表排序；
  • 需要稳定性的排序。
数组归并排序和链表归并排序示例已使用 C++17 编译，并在开启 -Wall -Wextra -Wpedantic -Werror 后通过空数组、重复值、负数及链表排序测试。

2.9 桶排序

基本思想：桶排序的思想不是基于比较来实现的，而是通过分配来实现的一种排序算法。设置固定数量的空桶；遍历数组，将每个元素放入对应的桶里；对每个非空桶进行排序，按照顺序把每个桶里的元素放回原数组。
平均时间复杂度：
最坏时间复杂度：
空间复杂度：
适用条件：数据分布均匀，数据范围有限。如整理扑克牌、给学生成绩排序。

3. 计数排序与基数排序

本章围绕「非比较排序」展开，先明确核心概念与适用边界。

3.1 非比较排序

本节从「计数排序」和「基数排序」两方面说明非比较排序。
3.1.1 计数排序
  • 适合整数键范围较小；
  • 时间复杂度通常为 O(n + k)；
  • 空间复杂度通常为 O(k)；
  • 是否稳定取决于具体实现。
3.1.2 基数排序
  • 按位或按字符分阶段排序；
  • 每一阶段通常要求稳定的子排序；
  • 复杂度取决于位数、基数和子排序；
  • 适合定长整数、字符串等特定键。

4. 数据结构与算法选择建议

  • vector 和数组适合需要随机访问及缓存友好的场景。
  • 需要链表排序：优先归并排序。
  • std::sort 适合一般数组排序；只有在教学、特定分区需求或需要自定义行为时再手写快速排序。
  • 只需要前 K 个：根据目标考虑维护大小为 k 的堆；找最大的 K 个通常维护小根堆，找最小的 K 个通常维护大根堆。
  • 查询很多且更新少：AVL 可能合适。
  • 增删查综合平衡：红黑树类结构常见。
  • 磁盘页和范围查询：B/B+ 树类结构。
  • tuple 可用于临时返回多个值。

5. 总结

查找与排序算法没有脱离数据规模和分布的“唯一最优解”。选择时应比较时间复杂度、额外空间、稳定性、是否原地、数据是否近乎有序，以及键值范围能否支持计数或基数方法。

6. 参考资料

  • 严蔚敏、李冬梅、吴伟民：《数据结构（C 语言版·第 2 版）》。
 
]]> <![CDATA[计算机组成原理笔记]]> https://www.yyshow.xyz/article/computer-architecture-cpu-bits https://www.yyshow.xyz/article/computer-architecture-cpu-bits Sat, 11 Jul 2026 00:00:00 GMT
 
本文整理 CPU 内部结构、指令周期、原码/反码/补码，以及 32 位和 64 位体系。

1. 计算机系统的基本组成

计算机系统的基本组成示意图
计算机系统的基本组成示意图
计算机系统的基本组成示意图 2
计算机系统的基本组成示意图 2
从经典冯·诺依曼模型看，计算机系统通常由以下部分组成：
  • 运算器；
  • 控制器；
  • 存储器；
  • 输入设备；
  • 输出设备。
现代实现中，运算器和控制器等集成在 CPU 内；主存储器保存正在运行的程序和数据；I/O 控制器和外设负责输入输出。

2. CPU 内部主要部件

本章从「控制单元（CU）」「算术逻辑单元（ALU）」和「寄存器」等方面说明 CPU 内部主要部件。

2.1 控制单元（CU）

控制单元负责：
  • 获取指令；
  • 对指令进行译码；
  • 产生控制信号；
  • 调度寄存器、执行单元、缓存和访存部件。
现代 CPU 的控制实现可能是硬连线控制、微程序控制或二者结合。

2.2 算术逻辑单元（ALU）

ALU 负责整数算术和逻辑操作，例如：
  • 加减；
  • 位与、位或、异或、取反；
  • 比较；
  • 移位。
浮点运算通常由浮点执行单元负责；现代处理器还包含 SIMD/向量执行单元、地址生成单元等。

2.3 寄存器

寄存器是 CPU 内部高速存储单元。
常见类别：
  • 通用寄存器：保存操作数、中间结果和地址。
  • 程序计数器 PC / 指令指针 IP：保存下一条将要获取的指令地址。
  • 指令寄存器 IR：教学模型中保存当前指令。
  • 状态寄存器 / 标志寄存器：记录零、进位、溢出、符号等状态。
  • 栈指针 SP：指向当前栈顶。
  • 控制寄存器：用于内存管理、特权级和系统控制。

2.4 Cache

Cache 保存近期或高概率再次访问的指令和数据，用来缩小 CPU 与主存之间的速度差距。
常见层级：
Cache 不是简单的“数据和指令仓库”，还涉及缓存行、局部性、替换策略、写策略和一致性协议。

2.5 内部互连和总线

CPU 内部通过数据通路和互连结构连接寄存器、执行单元、缓存等部件。
系统层面常区分：
  • 地址信息；
  • 数据信息；
  • 控制信息。
“数据总线、地址总线、控制总线”是功能上的分类，不应直接当作 CPU 的全部结构组成。

2.6 时钟、流水线和预测

现代 CPU 还常包含：
  • 时钟和时序电路；
  • 指令流水线；
  • 分支预测器；
  • 乱序执行调度器；
  • 重排序缓冲区；
  • 取指、译码和发射单元。
这些结构允许多条指令的不同阶段重叠执行。逻辑上仍可使用“取指—译码—执行”理解单条指令，但物理实现远比顺序模型复杂。

3. CPU 执行指令的基本过程

教学模型通常分为：
  1. 取指；
  1. 译码；
  1. 执行；
  1. 访存（如需要）；
  1. 写回；
  1. 更新下一条指令地址。

3.1 取指

  • PC 保存下一条指令地址；
  • CPU 请求对应地址的指令；
  • 指令通过缓存层次或主存进入 CPU；
  • PC 更新为顺序下一地址，或之后被跳转目标覆盖。

3.2 译码

译码单元分析：
  • 操作码；
  • 源操作数；
  • 目标操作数；
  • 寻址方式；
  • 立即数；
  • 是否需要访存或改变控制流。

3.3 执行

根据指令类型：
  • ALU 执行整数运算；
  • 浮点/向量单元执行对应运算；
  • 访存单元计算地址并读写缓存/内存；
  • 分支指令修改控制流；
  • 结果写回寄存器或内存。

3.4 PC 如何递增

PC 的更新步长由指令集和当前指令长度决定，不能直接由 CPU 位宽推断。
正确说法：
  • PC 按指令长度或 ISA 规定的指令宽度更新；
  • x86/x86-64 指令是变长的，一条指令可占不同字节数；
  • AArch64 的常规指令通常为固定 4 字节；
  • 遇到跳转、调用、返回、异常或中断时，PC 会改为目标地址；
  • CPU 是 32 位还是 64 位，不能直接决定每条指令都占 4 或 8 字节。

4. 原码、反码和补码

以下以 8 位有符号整数为例。

4.1 原码

  • 最高位表示符号：0 为正，1 为负；
  • 其余位表示绝对值。
问题：存在 +0 和 -0 两种零。

4.2 反码

  • 正数反码与原码相同；
  • 负数符号位不变，其余位取反。
仍然存在两种零。

4.3 补码

  • 正数补码与原码相同；
  • 负数补码通常可由“对应正数按位取反再加 1”得到。
8 位补码范围：

4.4 为什么使用补码

本节从「零只有一种表示」和「加减法可以统一到加法器」两方面说明为什么使用补码。
4.4.1 零只有一种表示
因此 8 位编码可以覆盖一个额外负数 -128。
4.4.2 加减法可以统一到加法器
计算：
可转换为：
丢弃超出 8 位的最高进位，得到 0000 0010，即 2。
更严谨地说，是将减法转换为加上被减数的相反数的补码，而不是笼统地说“加上这个数的补码”。

4.5 溢出

固定宽度补码运算会溢出。
8 位有符号数：
位模式结果为：
按 8 位补码解释为 -128。CPU 通常通过溢出标志等状态帮助软件判断。

5. 32 位和 64 位程序

本章从「32 位与 64 位的含义」「地址空间」和「数据模型」等方面说明 32 位和 64 位程序。

5.1 32 位与 64 位的含义

“32 位 CPU”或“64 位 CPU”并不是只指一个单一参数，常涉及：
  • 通用寄存器宽度；
  • 指令集架构；
  • 地址计算能力；
  • 指针和虚拟地址模型；
  • 操作系统 ABI；
  • 数据通路宽度。
不同架构的具体实现可能不同。

5.2 地址空间

32 位指针理论上可编码：
单个 32 位进程通常只能使用其中一部分，具体划分取决于操作系统。
64 位指针理论上可编码 16 EiB，但现代处理器和操作系统通常只实现较少的有效虚拟地址位数，例如常见的 48 位或 57 位地址形式。不能把“64 位”直接等同于现实中可用 16 EiB 内存。

5.3 数据模型

常见模型：
  • ILP32：int、long、指针通常为 32 位；
  • LP64：long 和指针为 64 位，int 为 32 位，常见于 64 位 Linux/macOS；
  • LLP64：long long 和指针为 64 位，long 仍为 32 位，常见于 64 位 Windows。
因此跨平台代码不能假设：
应使用 sizeof、固定宽度整数类型和 uintptr_t 等进行判断。

5.4 指令集和寄存器

以 x86 为例，x86-64：
  • 将部分通用寄存器扩展到 64 位；
  • 增加了更多通用寄存器；
  • 定义了新的调用约定和系统编程环境；
  • 提供 64 位地址和整数运算能力。
这些结论不能无条件推广到所有 CPU 架构。

6. 操作系统与程序兼容性

本章从「64 位 CPU 能否安装 32 位操作系统」「32 位 CPU 能否运行 64 位操作系统」和「64 位操作系统能否运行 32 位程序」等方面说明操作系统与程序兼容性。

6.1 64 位 CPU 能否安装 32 位操作系统

取决于该 CPU 是否保留对应兼容执行模式，以及设备是否仍有合适驱动。
传统 x86-64 处理器通常可以运行 32 位 x86 操作系统，但此时操作系统运行在 32 位模式，不是“64 位长模式下的兼容子模式”。
32 位系统仍可能通过 PAE 使用超过 4 GiB 的物理内存，但单个普通 32 位进程的虚拟地址空间仍受到 32 位地址范围限制。

6.2 32 位 CPU 能否运行 64 位操作系统

不能直接运行要求 64 位指令集和执行模式的操作系统内核，因为 CPU 缺少对应指令、寄存器和系统机制。

6.3 64 位操作系统能否运行 32 位程序

可能可以，但取决于：
  • 操作系统是否提供兼容层；
  • 是否安装 32 位运行库；
  • CPU 是否支持相应执行模式；
  • 程序是否依赖已经移除的驱动或组件。
64 位内核通常要求 64 位内核驱动，不能直接加载 32 位内核驱动。

6.4 64 位一定更快吗

不一定。
可能更快的场景：
  • 需要超过 4 GiB 地址空间；
  • 大量 64 位整数运算；
  • 得益于更多寄存器和更好的调用约定；
  • 数据库、虚拟机、科学计算、大型内容生产。
可能没有优势或产生额外成本：
  • 指针从 4 字节变为 8 字节，使数据结构变大；
  • 缓存中能容纳的对象减少；
  • 内存带宽和缓存压力增加；
  • 程序主要受磁盘、网络或 GPU 限制；
  • 只处理小整数和小规模数据。
性能最终取决于程序、编译器、ABI、微架构、内存行为和工作负载。

7. 总结

CPU 通过取指、译码和执行不断推进程序；补码让有符号整数的加减法可以复用同一套二进制运算规则。32 位与 64 位不仅影响寄存器和地址空间，也受到指令集、ABI、操作系统与应用依赖共同约束。
分析具体程序时，应明确讨论的是数据宽度、地址宽度、进程架构还是操作系统兼容层，避免把“64 位”简单等同于“必然更快”。

8. 参考资料

]]> <![CDATA[Git 与 SVN ]]> https://www.yyshow.xyz/article/version-control-git-svn https://www.yyshow.xyz/article/version-control-git-svn Mon, 22 Dec 2025 00:00:00 GMT
 
本文重点说明了 Git 的工作区、暂存区、本地仓库和远程仓库，以及 Git 与 SVN 的协作模型。

1. 版本控制解决什么问题

版本控制系统（VCS）用于记录文件随时间发生的变化，使开发者能够：
  • 查看谁在什么时间修改了哪些内容；
  • 对比两个版本之间的差异；
  • 恢复到历史版本；
  • 让多人并行开发并合并修改；
  • 通过分支隔离功能开发、修复和发布工作。

2. Git 的基本模型

Git 是分布式版本控制系统。每次正常克隆都会得到项目历史和对象数据库的本地副本，因此大多数查看历史、创建分支、提交等操作可以离线完成。
Git 日常使用涉及四个位置：
  1. 工作区（Working Tree）：正在编辑的实际文件。
  1. 暂存区（Index / Staging Area）：下一次提交准备包含的快照。
  1. 本地仓库（Local Repository）：已经创建的提交历史。
  1. 远程仓库（Remote Repository）：GitHub、GitLab 或公司服务器上的共享仓库。
典型数据流：
从远程获取数据：
Git 并不要求“每次修改前必须先同步”。但团队开发时，在开始工作或推送前获取远程最新状态，可以减少冲突。

3. Git 的三种使用方式

  • 命令行 CLI：Git Bash、PowerShell、Terminal。
  • 图形界面 GUI：Fork、SourceTree、GitKraken 等。
  • IDE 集成：Visual Studio、VS Code、JetBrains Rider 等。
GUI 不是 CUI。CUI 通常指字符用户界面，GUI 指图形用户界面。

4. 常用命令分类

本章从「初始化和克隆」「查看状态和差异」和「暂存和提交」等方面说明常用命令分类。

4.1 初始化和克隆

git init 将当前目录初始化为 Git 仓库；git clone 会复制远程仓库并自动设置默认远程名 origin。

4.2 查看状态和差异

  • git diff：工作区与暂存区之间的差异。
  • git diff --staged：暂存区与当前提交之间的差异。
  • git log：查看提交历史。

4.3 暂存和提交

git commit -a -m "..." 只会自动暂存已经被 Git 跟踪的文件的修改和删除，不会自动加入新建的未跟踪文件。

4.4 删除和重命名

直接在文件管理器中删除或重命名也可以，但之后仍需使用 git add -A 记录变化。

4.5 远程仓库

当前新仓库通常使用 main 作为默认分支，但实际名称应通过 git branch --show-current 确认，不能固定假设为 master。

4.6 分支

git checkout 仍然可用，但现代 Git 将常见职责拆分为：
  • git switch：切换或创建分支；
  • git restore：恢复文件；
  • git checkout：兼容旧用法，也可处理更多低层场景。

4.7 标签

正确的批量推送参数是 --tags，不是 --tag。

4.8 临时保存

stash 适合暂时切换任务，不应代替正常提交和分支。

5. 撤销操作：restore、reset、revert

这是 Git 最容易混淆的部分。

5.1 git restore

用于恢复工作区文件或取消暂存：
第一条会丢失未提交修改，执行前应确认。

5.2 git reset

reset 可以移动当前分支的 HEAD，并根据模式影响暂存区和工作区：
  • --soft：只移动 HEAD，保留暂存区和工作区。
  • --mixed：移动 HEAD 并重置暂存区，保留工作区；这是默认模式。
  • --hard：同时重置 HEAD、暂存区和工作区，可能永久丢失未提交修改。
git reset --hard 不应随意用于已经推送并被他人使用的共享历史。

5.3 git revert

revert 不改写已有历史，而是创建一个新的“反向提交”。对已经推送的公共分支，通常优先使用 revert。

5.4 恢复误删提交

只要对象尚未被垃圾回收，reflog 经常可以找回本地误操作前的提交。

6. .gitignore

.gitignore 用来忽略不应进入仓库的文件，例如：
  • 编译输出；
  • 临时缓存；
  • IDE 本地设置；
  • 密钥和环境变量；
  • Unity 的 Library/、Temp/、Logs/ 等可再生成目录。
注意：
  • .gitignore 只影响尚未被跟踪的文件；
  • 已经提交过的文件不会因为后来加入忽略规则就自动停止跟踪；
  • 可使用 git check-ignore -v <文件> 排查匹配了哪条规则。

7. 冲突处理

冲突通常发生在两条开发线修改了相同文件的相同区域时。
基本流程：
常见冲突标记：
版本控制系统只能帮助标出文本冲突，业务语义是否正确仍需开发者判断。

8. SVN 的基本模型

SVN 是集中式版本控制系统。版本历史的权威副本位于中央仓库，开发者在本地使用工作副本。
常见流程：
准确理解：
  • 即使中央服务器不可用，开发者通常仍能编辑本地工作副本；
  • 但无法更新、提交或访问完整中央历史；
  • SVN 默认也支持“复制—修改—合并”模型，并不是所有文件都必须加锁；
  • 对 PSD、音频、场景二进制文件等难以合并的资源，可以使用锁机制避免多人同时修改。

9. Git 与 SVN 对比

本章从「Git」和「SVN」两方面说明 Git 与 SVN 对比。

9.1 Git

  • 分布式，本地仓库包含历史；
  • 本地提交、分支和查看历史速度快；
  • 分支成本低，适合并行功能开发；
  • 离线可完成多数操作；
  • 学习成本相对更高；
  • 大型二进制资源需要 Git LFS 等补充方案。

9.2 SVN

  • 集中式，中央仓库是权威历史；
  • 权限和目录级管理直观；
  • 工作副本操作模型较简单；
  • 对需要锁定的二进制美术资源较友好；
  • 网络或中央服务故障会阻断更新和提交；
  • 分支通常通过目录复制实现，使用习惯与 Git 不同。

10. 游戏项目中的选型建议

本章从「代码为主的小型项目」和「美术资源很多的集中式流程」两方面说明游戏项目中的选型建议。

10.1 代码为主的小型项目

优先考虑 Git：
  • 使用功能分支；
  • 代码评审通过 Pull Request；
  • 将可再生成目录加入 .gitignore；
  • 大文件使用 Git LFS。

10.2 美术资源很多的集中式流程

SVN 或其他集中式资产管理工具仍可能更适合：
  • 对不可合并文件设置锁；
  • 规定场景、Prefab 和大资源的负责人；
  • 提交前先更新并解决冲突；
  • 将代码评审和资源审批流程分开。

11. 总结

Git 适合以本地提交、分支和合并为核心的分布式协作；SVN 适合强调集中权限、目录级管理和统一主线的流程。选型时应结合资产类型、团队规模、网络环境和发布方式，而不是只比较命令数量。
无论使用哪种工具，都要先确认工作区状态和变更范围，再执行提交、回退或冲突处理。

12. 官方参考

]]> <![CDATA[TypeScript 学习笔记]]> https://www.yyshow.xyz/article/typescript-study-notes https://www.yyshow.xyz/article/typescript-study-notes Sun, 05 Jul 2026 00:00:00 GMT

1. TypeScript 概述

TypeScript 是 JavaScript 的超集，在 JavaScript 的基础上增加了静态类型系统。
它并不会取代 JavaScript，而是在代码编译阶段帮助开发者提前发现一部分类型错误，最后仍然会被编译成 JavaScript 运行。

1.1 TypeScript 的优点

  • 编译阶段可以发现部分类型错误；
  • IDE 的代码提示、跳转和重构能力更强；
  • 函数参数、返回值和数据结构更清晰；
  • 大型项目和多人协作时更容易维护；
  • 修改接口或重构代码时更加安全。

1.2 TypeScript 的缺点

  • 需要额外学习类型系统；
  • 类型写得过于复杂时，可读性可能下降；
  • 第三方库缺少类型声明时，需要自己补充 .d.ts 文件；
  • 如果项目中大量使用 any，类型系统会逐渐失去意义。

1.3 适用场景

TypeScript 比较适合：
  • 大型项目；
  • 多人协作项目；
  • 接口和数据结构较复杂的项目；
  • 前端工程化项目；
  • Cocos Creator 游戏客户端项目；
  • 需要长期维护和频繁重构的项目。
在 Cocos Creator 项目中，TypeScript 可以明确描述 Node、Button、Label、资源对象、商品数据、关卡配置等类型，减少组件获取和数据传递时的错误。

2. TypeScript 基础类型

TypeScript 中常见的基础类型包括：
JavaScript 原有的基础值类型包括：
  • string
  • number
  • boolean
  • null
  • undefined
  • symbol
  • bigint
TypeScript 在此基础上又提供了：
  • 数组；
  • 元组；
  • 枚举；
  • 对象类型；
  • 联合类型；
  • 交叉类型；
  • any；
  • unknown；
  • void；
  • never。

3. 数组与元组

本章从「Array 数组」和「Tuple 元组」两方面说明数组与元组。

3.1 Array 数组

数组表示一组数量通常不固定、类型相同或结构相近的数据。
数组也可以使用联合类型：
所以“数组中的元素只能有一种类型”并不准确，更准确的说法是：数组中的元素必须符合数组声明的元素类型。

3.2 Tuple 元组

元组用于表示固定长度、固定位置类型的数据。
其中：
  • 第 0 位必须是 string；
  • 第 1 位必须是 number。
常见使用场景：
注意：数组适合表示一组同类数据，元组适合表示固定结构的数据。

4. 枚举 enum

枚举用于定义一组有限的命名常量。
字符串枚举：
常见使用场景：
  • 游戏状态；
  • 角色状态；
  • 网络消息类型；
  • 事件类型；
  • UI 面板类型；
  • 道具类型；
  • 动画状态。
注意：enum 编译后通常会生成运行时代码。
如果只需要类型约束，也可以使用联合字面量：

5. keyof、typeof 与 as const

本章从「keyof」「typeof」和「keyof typeof」等方面说明 keyof、typeof 与 as const。

5.1 keyof

keyof 用于获取一个对象类型中所有键组成的联合类型。
常见写法：

5.2 typeof

typeof 在 JavaScript 和 TypeScript 中有两个不同语境。
5.2.1 JavaScript 运行时
5.2.2 TypeScript 类型语境
此时 User 等价于：
简单理解：
  • keyof：这个类型有哪些字段；
  • typeof：这个变量是什么类型。

5.3 keyof typeof

执行顺序：
  1. typeof GoodsType 获取对象类型；
  1. keyof 再获取该类型所有键。

5.4 as const

as const 会让 TypeScript 使用更精确的字面量类型，而不是把数据宽化成普通的 string[]。

6. any、unknown、void 与 never

本章从「any」「unknown」和「void」等方面说明 any、unknown、void 与 never。

6.1 any

any 表示任意类型，会关闭大部分类型检查。
上面的代码编译时可能不报错，但运行时可能出现异常。
注意：大量使用 any 会让 TypeScript 逐渐失去意义。

6.2 unknown

unknown 同样表示未知类型，但比 any 更安全。
在使用 unknown 之前，必须先进行类型判断、类型收窄或断言。

6.3 void

void 通常表示函数没有需要使用的返回值。

6.4 never

never 表示永远不会正常产生的值。
也可以用于穷尽检查：

7. 联合类型与交叉类型

本章从「联合类型」和「交叉类型」两方面说明联合类型与交叉类型。

7.1 联合类型

联合类型使用 |，表示一个值可以是多种类型中的一种。
对象联合通常会和可辨识联合一起使用：

7.2 交叉类型

交叉类型使用 &，表示同时拥有多个类型的全部成员。
简单理解：
  • 联合类型：或；
  • 交叉类型：且。

8. type 与 interface

type 和 interface 都可以描述对象结构。

8.1 共同点

  • 都可以描述对象结构；
  • 都可以被类实现；
  • 都可以扩展已有类型。

8.2 interface 的特点

interface 支持声明合并：
最终会合并为同一个 Window 类型。

8.3 type 的特点

type 可以描述更多复杂类型：
常见选择方法：
  • 描述对象结构、公共接口时优先使用 interface；
  • 联合类型、交叉类型、元组和复杂类型运算使用 type。

9. 泛型

泛型可以理解为“类型参数”。
它允许函数、类和接口在定义时不写死具体类型，在使用时再确定类型。

9.1 函数泛型

很多情况下 TypeScript 可以自动推导泛型参数：

9.2 接口泛型

9.3 类泛型

泛型的作用：
  • 提高代码复用性；
  • 保留明确类型；
  • 减少 any；
  • 让通用数据结构和工具函数更加安全。
在游戏项目中，资源加载、对象池、接口返回结果和列表组件都适合使用泛型。

10. TypeScript 工具类型

TypeScript 内置了许多常用工具类型。

10.1 Partial

将所有属性变成可选属性：
适合局部更新：

10.2 Required

将所有属性变成必填属性：

10.3 Readonly

将所有属性变成只读属性：

10.4 Pick

选取部分字段：

10.5 Omit

排除部分字段：

10.6 Record

创建键值映射：

10.7 ReturnType 与 Parameters

常见使用总结：
  • Partial：局部修改；
  • Pick：选择字段；
  • Omit：排除字段；
  • Record：字典映射；
  • ReturnType：获取函数返回值类型；
  • Parameters：获取函数参数元组。

11. 类与访问修饰符

TypeScript 支持 public、protected 和 private。
修饰符
当前类
子类
类外部
public
可以
可以
可以
protected
可以
可以
不可以
private
可以
不可以
不可以
public 是默认修饰符。

11.1 private 与 # 私有字段

区别：
  • private 主要由 TypeScript 在编译阶段检查；
  • #salary 是 JavaScript 原生私有字段；
  • # 私有字段在运行时也不能从类外部直接访问。

12. 抽象类

抽象类使用 abstract class 声明，不能被直接实例化，只能被继承。
抽象类可以：
  • 提供公共属性；
  • 提供已经实现的方法；
  • 定义必须由子类实现的抽象方法；
  • 作为一组子类的公共基类。
抽象类和接口的主要区别：
  • 抽象类会生成运行时代码；
  • 接口只用于类型检查；
  • 一个类只能继承一个抽象类；
  • 一个类可以实现多个接口。

13. 常见符号

本章说明可选属性、可选链与空值合并等常见符号的含义和使用边界。

13.1 ? 可选

13.2 ?. 可选链

左侧为 null 或 undefined 时，不再继续访问，结果为 undefined。
Cocos 中常见写法：

13.3 ?? 空值合并

只有左侧是 null 或 undefined 时才使用右侧默认值。

13.4 ! 非空断言

表示开发者确定结果不为空。
注意：非空断言只关闭编译检查，不会自动保证运行时一定有值。

13.5 ! 属性确定赋值断言

表示该属性会在其他位置完成初始化。

13.6 _ 下划线

数字分隔符：
表示暂时不使用的参数：

13.7 & 与 |

  • &：交叉类型；
  • |：联合类型。

13.8 #

JavaScript 原生私有字段：

14. 模块导入与路径解析

示例：
假设当前文件是：
解析过程：
具体匹配到 .ts、.tsx、.d.ts、.js、package.json 导出项还是其他文件，取决于：
  • moduleResolution 配置；
  • 使用的运行时；
  • 打包器；
  • package.json 的 exports 和 imports；
  • TypeScript 版本和其他编译选项。
因此，“不以 ./ 或 ../ 开头就一定从 node_modules 查找”过于简化。它属于裸模块说明符（bare specifier），如何解析取决于当前模块解析模式。

14.1 常见路径形式

14.2 路径别名

@/ 并不是 JavaScript 或 TypeScript 内置语法，需要在 tsconfig.json 中配置，并确保运行时或打包器也理解相同映射。
只配置 TypeScript 可能只让编辑器和类型检查通过；实际运行时仍需由 Vite、Webpack、Node.js 或对应框架配置解析。

14.3 是否写扩展名

在很多 TypeScript 项目中，相对导入会省略扩展名：
是否允许直接写 .ts，取决于编译配置和运行方式。不要把“TypeScript 总是不允许扩展名”或“总是允许扩展名”当成固定规则。

14.4 导入方式

import type 会明确表示只在类型检查阶段使用，避免无意生成运行时导入。

15. 扩展全局属性与第三方模块声明

本章从「扩展 window」和「声明第三方模块」两方面说明扩展全局属性与第三方模块声明。

15.1 扩展 window

可以创建 global.d.ts：

15.2 声明第三方模块

第三方库没有类型声明时，可以自己补充：
全局变量：
.d.ts 文件只负责提供类型声明，不会自动实现真实功能。

16. Cocos Creator 中的 TypeScript 实践

在 Cocos Creator 项目中，TypeScript 常用于：
  • UI 组件；
  • 节点和组件绑定；
  • 游戏状态管理；
  • 资源加载；
  • 对象池；
  • 订单和商品数据；
  • 关卡配置；
  • 异步流程。

16.1 编辑器属性绑定

明确的组件类型可以让 IDE 提供正确提示，也能减少把 Node、Button 和 Label 混用的问题。

16.2 数据结构

16.3 异步资源加载

多个资源并行加载：

16.4 实际使用中的问题

项目赶进度时容易出现：
这种写法虽然方便，但会绕过类型检查。
更好的方式是：
  • 给组件声明明确类型；
  • 使用接口描述数据结构；
  • 使用泛型封装资源加载；
  • 对外部数据先使用 unknown，再进行类型判断；
  • 尽量减少强制断言和 any。

17. 常见易错点

  • unknown 不能直接使用，必须先进行类型收窄；
  • any 会关闭大部分类型检查；
  • void 和 never 含义不同；
  • 数组可以使用联合元素类型，不是只能存一种类型；
  • 元组强调固定长度和固定位置类型；
  • keyof 获取类型的键，typeof 获取变量的类型；
  • enum 通常会产生运行时代码；
  • interface 支持声明合并；
  • type 更适合联合、交叉、元组和复杂类型运算；
  • private 主要是 TypeScript 编译期限制；
  • # 是 JavaScript 原生运行时私有字段；
  • ?. 只处理 null 和 undefined；
  • ?? 不会把 0、空字符串和 false 当成空值；
  • 非空断言 ! 不能消除真实的运行时空引用；
  • .d.ts 只描述类型，不会实现第三方 SDK。

18. 总结

TypeScript 的价值在于把许多接口约束提前到编译阶段。实际项目中应从清晰的数据模型和函数边界开始，再使用泛型、联合类型、类型守卫和工具类型表达复用关系。
类型声明不能替代运行时校验；外部输入、网络数据和跨版本资源仍需要在运行时检查。

19. 参考资料

]]> <![CDATA[JavaScript 学习笔记]]> https://www.yyshow.xyz/article/javascript-core-notes https://www.yyshow.xyz/article/javascript-core-notes Fri, 10 Jul 2026 00:00:00 GMT
本文集中整理 JavaScript 中容易混淆的三组基础知识：数据类型、for...in 与 for...of，以及 splice、slice 与 toSpliced。读完后可以根据遍历目标和是否修改原数组选择合适的写法。

1. JavaScript 数据类型

JavaScript 的值可以分为原始值（primitive）和对象（object）。

1.1 七种原始类型

  • undefined
  • null
  • boolean
  • number
  • bigint
  • string
  • symbol
原始值不可变。所谓不可变，是指不能直接改变这个值本身；变量仍然可以重新赋值。

1.2 对象类型

除原始值外，其余值都属于对象，包括：
  • 普通对象 Object
  • 数组 Array
  • 函数 Function
  • 日期 Date
  • 正则表达式 RegExp
  • Map、Set
  • Promise
数组和函数在类型体系上也是对象，但函数还具有可调用能力。

1.3 typeof 常见结果

判断数组应使用：
判断 null 应直接比较：

1.4 number 的注意事项

JavaScript 的普通数字采用 IEEE 754 双精度浮点格式，因此：
需要精确处理货币时，常见做法是使用整数最小单位，例如把 10.25 元保存为 1025 分；超出安全整数范围时可考虑 bigint。
number 与 bigint 不能直接混合运算：

2. for...in 与 for...of

本章比较对象键遍历、可迭代值遍历和数组遍历三类场景。

2.1 for...in

for...in 遍历对象的可枚举字符串属性键，也可能包含原型链上的属性。
现代代码优先使用 Object.hasOwn(obj, key)，而不是直接调用 obj.hasOwnProperty(key)，因为对象可能没有继承该方法，或存在同名属性。
适合场景：
  • 枚举普通对象的键；
  • 需要处理属性名；
  • 明确理解原型链和可枚举性。

2.2 for...of

for...of 遍历可迭代对象产生的值。
常见可迭代对象：
  • Array
  • String
  • Map
  • Set
  • TypedArray
  • NodeList
  • 自定义实现 [Symbol.iterator] 的对象

2.3 为什么不推荐用 for...in 遍历数组

可能输出：
而且数组索引以字符串键出现，遍历顺序和数组值语义也不是 for...in 的设计重点。
需要数组值：
需要索引和值：
需要支持 break、continue 或 await 时，for...of 通常比 .forEach() 更合适。

3. splice、slice 与 toSpliced

本章从「splice：修改原数组」「slice：提取浅拷贝，不修改原数组」和「toSpliced：不修改原数组的增删改」等方面说明 splice、slice 与 toSpliced。

3.1 splice：修改原数组

签名：
返回被删除元素组成的新数组。

3.2 slice：提取浅拷贝，不修改原数组

签名：
区间为左闭右开 [start, end)。
“浅拷贝”意味着嵌套对象仍然共享引用：

3.3 toSpliced：不修改原数组的增删改

现代 JavaScript 提供 toSpliced：
在 React 等强调不可变更新的场景中，toSpliced 或展开运算符通常比直接 splice 更安全。

4. 快速选择

  • 遍历对象键：Object.keys()、Object.entries() 或谨慎使用 for...in。
  • 遍历数组和集合值：for...of。
  • 需要索引：普通 for、entries() 或 .forEach()。
  • 修改原数组并插入、删除、替换：splice。
  • 截取子数组且不改原数组：slice。
  • 想使用 splice 的语义但保持不可变：toSpliced。

5. 常见易错点

  • typeof null 返回 "object"，不能用它判断 null。
  • 数组也是对象，判断数组使用 Array.isArray。
  • for...in 得到键，for...of 得到迭代值。
  • for...in 可能遍历到继承的可枚举属性。
  • splice 会修改原数组，slice 不会。
  • slice 是浅拷贝，不会递归复制嵌套对象。

6. 总结

JavaScript 中应先区分值的类型，再根据目标选择遍历和数组操作：对象键适合 Object.keys()、Object.entries() 或谨慎使用 for...in，可迭代值适合 for...of；需要原地修改数组时使用 splice，需要新数组时使用 slice 或 toSpliced。

7. 官方参考

]]> <![CDATA[C++ 学习笔记]]> https://www.yyshow.xyz/article/cpp-study-notes https://www.yyshow.xyz/article/cpp-study-notes Sat, 12 Jul 2025 00:00:00 GMT

1. 程序结构与类型系统

本章从「C++ 程序的基本结构」「基本数据类型」和「初始化与类型推导」等方面说明程序结构与类型系统。

1.1 C++ 程序的基本结构

一个最小的 C++ 程序由头文件、函数和语句组成：
  • #include <iostream> 引入标准输入输出相关声明。
  • main 是程序入口。
  • std::cout 表示标准输出流。
  • return 0 表示程序正常结束。
源文件通常经过预处理、编译、汇编和链接后生成可执行文件：
头文件主要保存声明，源文件保存定义。模板、inline 函数和部分编译期代码通常需要在头文件中提供完整定义，因为编译器必须在实例化位置看到实现。
1.1.1 命名空间
标准库名称位于 std 命名空间中：
using namespace std; 会把整个命名空间引入当前作用域，容易造成名称冲突。头文件中应避免使用这种写法；规模较大的项目也更适合明确写出 std::。

1.2 基本数据类型

C++ 的基础类型包括布尔、字符、整数和浮点数：
不同平台对部分类型的宽度规定不同。sizeof 返回对象或类型占用的字节数：
需要固定宽度整数时，可以使用 <cstdint> 中的类型：
sizeof 的单位是字节。long、指针和其他实现相关类型的宽度不能脱离目标平台直接写死。
1.2.1 有符号与无符号整数
有符号整数可以表示负数；无符号整数只表示非负值。无符号整数运算按模 回绕，有符号整数溢出属于未定义行为。
位标记更适合使用无符号整数：
循环下标、容器长度和有符号整数混合比较时，容易触发隐式转换。无法确认类型范围时，应先统一类型，再执行比较。
1.2.2 浮点数精度
许多十进制小数不能被有限二进制位精确表示，因此浮点计算通常不直接使用 == 判断结果：
固定误差适合数值范围稳定的场景。数值跨度较大时，还需要结合相对误差判断。

1.3 初始化与类型推导

C++ 支持多种初始化形式：
{}花括号初始化能够阻止部分窄化转换：
局部基础类型未初始化时，其值通常不确定：
auto 根据初始化表达式推导类型：
auto 会忽略顶层 const 和引用属性。需要保留引用或常量语义时，应明确写出：

1.4 const 与 constexpr

const 表示对象不能通过当前访问路径被修改：
constexpr 表示对象或函数可以参与常量表达式求值：
constexpr 变量同时具有 const 属性。constexpr 函数在参数满足常量表达式要求时可在编译期求值，也可以在运行期调用。
成员函数末尾的 const 表示该函数不修改对象的可观察状态：

1.5 运算符与表达式

整数除法会舍弃小数部分：
逻辑运算符 && 和 || 具有短路行为：
只有左侧条件满足继续计算的要求时，右侧表达式才会执行。
常用位运算符包括：
  • &：按位与；
  • |：按位或；
  • ^：按位异或；
  • ~：按位取反；
  • <<：左移；
  • >>：右移。
位运算优先使用无符号类型，并避免移位位数超出类型宽度。

2. 字符串

本章从「C 风格字符串」「std::string」和「字符串与数字转换」等方面说明字符串。

2.1 C 风格字符串

C 风格字符串是以空字符 \0 结尾的字符序列：
内存中实际保存：
字符串字面量不应被修改：
如果强行去掉 const 并尝试修改字符串字面量，程序行为未定义。需要可修改的字符序列时，可以使用字符数组：
<cstring> 提供常见 C 字符串函数：
strcpy 和 strcat 依赖调用者保证目标缓冲区空间充足。空间不足会造成越界写入。普通 C++ 业务代码优先使用 std::string，C 风格字符串主要用于兼容 C 接口、底层库和固定格式缓冲区。

2.2 std::string

std::string 管理字符存储和生命周期，支持拼接、查找、插入和删除：
常用接口：
字符访问方式：
  • operator[] 不执行边界检查；
  • at 越界时抛出 std::out_of_range；
  • size() 和 length() 对 std::string 等价。
size 表示当前字符数量，capacity 表示已经分配的容量：
shrink_to_fit 是非强制请求，标准库实现可以选择不缩容。
与 C 接口协作时，可以通过 c_str() 取得以 \0 结尾的只读字符指针：
字符串发生修改或重新分配后，之前取得的指针可能失效。

2.3 字符串与数字转换

输入格式错误或数值超出范围时，stoi、stoll 和 stod 会抛出异常。处理大量不可信文本或性能敏感的解析时，可以使用 <charconv> 中的 std::from_chars。
 

3. 函数与参数传递

本章从「不同类型的参数传递」和「函数重载」两方面说明函数与参数传递。

3.1 不同类型的参数传递

按值传递会创建参数副本：
引用参数直接绑定到调用者对象：
较大的只读对象通常使用常量引用传递：
指针适合表达“对象可能不存在”或需要与底层接口交互的场景：
选择参数形式时，可以先判断两个问题：
  1. 函数是否需要修改实参？
  1. “没有对象”是否属于合法状态？
需求
推荐形式
小型只读值
按值传递 T
大型只读对象
常量引用 const T&
必须存在且需要修改
引用 T&
允许为空且不转移所有权
指针 T*
需要取得所有权
智能指针或按值接收资源对象

3.2 函数重载

同一作用域中，函数可以通过不同参数列表形成重载：
返回类型不能单独构成重载。默认参数与函数重载同时使用时，需要检查调用是否产生二义性。
 

4. 指针与引用

指针保存对象地址，可以为空，也可以重新指向其他对象：
引用是已有对象的别名，声明时必须绑定对象，之后不能改为绑定另一个对象：
指针和引用的主要区别：
  • 指针存在 nullptr 状态，引用在正常语言语义中必须绑定有效对象；
  • 指针可以重新赋值为另一个地址，引用不能重新绑定；
  • 指针通过 * 和 -> 访问目标，引用按对象语法使用；
  • 裸指针和引用通常只表达访问关系，不自动说明资源所有权。
不要把“引用一定不占内存”当作语言规则。编译器可以根据实现需要为引用保留存储，程序应只依赖引用的语言语义。

4.1 nullptr

现代 C++ 使用 nullptr 表示空指针：
nullptr 具有专门的空指针类型，可以避免 NULL 被当成整数常量后引发重载歧义。

4.2 指向常量的指针与常量指针

  • const int*：不能通过该指针修改目标，指针本身可以改指向；
  • int* const：指针本身不能改指向，可以修改目标；
  • const int* const：指针和目标访问权限都受限。

4.3 智能指针

4.3.1 std::unique_ptr
unique_ptr 表示独占所有权，不能复制，只能移动：
独占关系能够成立时，优先使用 unique_ptr。它的所有者明确，生命周期容易判断。
4.3.2 std::shared_ptr
shared_ptr 使用引用计数表示共享所有权：
最后一个拥有者销毁时，对象才会释放。共享所有权会增加控制块、引用计数和并发访问相关开销，不应仅为“避免思考生命周期”而使用。
4.3.3 std::weak_ptr
weak_ptr 观察 shared_ptr 管理的对象，但不增加强引用计数。它常用于打破循环引用：

4.4 悬空引用与失效规则

以下情况容易产生悬空指针或悬空引用：
  • 返回局部变量的地址或引用；
  • 对象销毁后继续访问其成员；
  • 容器扩容后继续使用旧迭代器、指针或引用；
  • 移动、交换或删除对象后仍假设原地址关系不变；
  • 异步任务保存了生命周期不足的捕获对象。
错误示例：
调用者得到的引用在函数返回后已经失效。应按值返回，或返回生命周期覆盖调用范围的对象引用。

5. 对象生命周期与资源管理

本章从「存储期与对象生命周期」「new 与 delete」和「RAII」等方面说明对象生命周期与资源管理。

5.1 存储期与对象生命周期

存储期描述对象所占存储空间存在多久；生命周期描述对象从构造完成到析构开始的有效时间。两者相关，但不能完全等同。
常见存储期包括：
  1. 自动存储期：局部对象通常在进入作用域时创建，离开作用域时销毁。
  1. 静态存储期：全局对象、命名空间对象和静态局部对象通常存活到程序结束。
  1. 线程存储期：thread_local 对象与线程生命周期关联。
  1. 动态存储期：通过动态分配获得，由程序或资源管理对象控制释放时机。
工程中常说的“栈、堆、全局区”便于理解典型实现，但 C++ 标准主要规定对象语义和存储期，不强制所有实现采用完全相同的物理内存布局。

5.2 new 与 delete

动态创建单个对象：
动态数组必须配对使用 new[] 和 delete[]：
常见错误包括：
  • 忘记释放，造成资源泄漏；
  • 重复释放同一地址；
  • 使用错误的 delete 形式；
  • 释放后继续访问悬空指针；
  • 一个地址由多个对象同时负责释放。
把某个指针设为 nullptr 只能防止继续通过该变量访问旧地址，不能使其他别名指针自动失效。

5.3 RAII

RAII 将资源的获取和释放绑定到对象生命周期。构造函数建立资源所有权，析构函数负责释放资源。作用域结束、提前返回或异常传播时，局部对象都会按规则析构，因此资源清理不依赖手工补写多条释放路径。
std::ofstream 离开作用域时会自动关闭文件。锁、文件、容器、智能指针和线程封装都可以使用同样的资源管理思路。

6. 类、对象与多态

本章从「类的职责」「构造函数与成员初始化列表」和「析构函数」等方面说明类、对象与多态。

6.1 类的职责

类把数据、约束和操作组织在一起。字段保存对象状态，成员函数维护状态变化，访问控制负责保护类的不变量。
构造函数建立合法初始状态，TakeDamage 保证生命值不会小于零。外部代码不能绕过接口随意破坏对象状态。

6.2 构造函数与成员初始化列表

成员初始化列表在进入构造函数体前直接初始化成员：
成员的实际初始化顺序由它们在类中的声明顺序决定，与初始化列表中的书写顺序无关。初始化列表应尽量保持与成员声明一致，避免阅读误导和编译器警告。
explicit 可以阻止单参数构造函数参与不期望的隐式转换：

6.3 析构函数

析构函数在对象生命周期结束时执行，用于释放对象直接拥有的资源：
手工管理裸资源会同时引出拷贝、赋值、异常安全和所有权问题。实际项目更适合使用 std::vector<int> 或 std::unique_ptr<int[]>，让标准库对象负责资源释放。

6.4 this、静态成员与友元

this 指向当前对象：
静态成员属于类，而不是某个对象：
友元可以访问类的非公有成员，但会扩大耦合范围。只有运算符重载、紧密协作类型或明确的底层接口确实需要时才使用。

6.5 继承与运行时多态

继承表达“派生类属于基类的一种”，运行时多态通过虚函数完成：
override 要求编译器检查派生类函数是否真正覆盖基类虚函数，可防止参数或 const 不一致造成的隐藏错误。
6.5.1 虚析构函数
当对象可能通过基类指针删除时，基类析构函数必须为虚函数：
如果基类析构函数不是虚函数，通过基类指针销毁派生对象会导致未定义行为。
6.5.2 对象切片
派生对象按值赋给基类对象时，派生部分会被截断：
需要保留动态类型时，应通过引用、指针或智能指针使用多态对象。
6.5.3 组合与继承
  • 继承适合稳定的“是一个”关系，并要求派生类能够满足基类接口约束。
  • 组合适合“拥有一个”或“使用一个”关系，依赖更容易替换。
游戏角色由移动、生命、技能和背包等能力组成时，组件组合通常比多层继承更灵活。

7. 拷贝、移动

7.1 浅拷贝与深拷贝

编译器生成的成员逐一拷贝对值类型成员通常足够。类直接拥有裸指针资源时，默认拷贝只会复制地址，多个对象可能指向同一块资源：
如果两个 Buffer 对象复制后都在析构时释放 data，会发生重复释放。深拷贝需要为新对象重新分配资源并复制内容。
实际项目优先使用能够正确复制或禁止复制的标准库成员：
此时编译器生成的拷贝、移动和析构行为已经符合资源语义。

7.2 零法则、三法则与五法则

本节从「零法则」「三法则」和「五法则」等方面说明零法则、三法则与五法则。
7.2.1 零法则
类只使用标准库容器、字符串和智能指针管理资源时，通常不需要手写析构、拷贝或移动函数。零法则应作为默认选择。
7.2.2 三法则
类需要自定义以下任意一个函数时，通常需要同时检查另外两个：
  1. 析构函数；
  1. 拷贝构造函数；
  1. 拷贝赋值运算符。
7.2.3 五法则
C++11 增加移动语义后，还需要检查：
  1. 移动构造函数；
  1. 移动赋值运算符。
五法则描述的是资源类需要保持的一组一致语义，不代表所有类都应手写五个函数。

7.3 左值、右值与引用折叠

左值通常表示具有稳定身份、可以取得地址的表达式；右值通常表示临时值或即将被消费的对象。
常见引用形式：
  • T&：左值引用；
  • const T&：可绑定左值和右值，常用于只读参数；
  • T&&：右值引用，用于移动语义和完美转发。
命名后的右值引用变量本身是左值：

7.4 std::move

std::move 不执行资源移动，它把表达式转换为可供移动操作接收的值类别：
target 的构造函数可以接管 source 的内部资源。移动后的标准库对象仍处于有效但通常未指定的状态，可以析构、重新赋值或调用明确允许的操作，但不应假设原内容仍然存在。
移动仅在目标类型提供移动操作时发生。对 const 对象调用 std::move 通常仍会选择拷贝，因为移动构造函数一般需要修改源对象。

7.5 移动构造与移动赋值

资源类的移动操作通常接管资源，并把源对象置于可安全析构的状态：
实际项目仍应优先用标准库类型消除手工资源管理。该示例用于说明移动操作需要维护源对象和目标对象的生命周期安全。

7.6 拷贝消除

编译器可以在部分返回值和临时对象场景中省略拷贝或移动。C++17 对若干纯右值初始化场景规定了保证拷贝消除：
按值返回局部对象通常比返回裸指针更安全，也不应为了“避免拷贝”而习惯性返回动态分配对象。

8. 运算符重载与类型转换

本章从「运算符重载」「四种命名类型转换」和「隐式转换与 explicit」等方面说明运算符重载与类型转换。

8.1 运算符重载

运算符重载用于让自定义类型遵循已有运算符的语义：
重载原则：
  • 保持运算符的常见含义；
  • 不通过运算符隐藏昂贵或意外的副作用；
  • 对称二元运算符通常实现为非成员函数；
  • 赋值、下标、调用和成员访问等运算符必须按语言规则实现为成员函数；
  • 返回类型和参数形式应支持自然的组合使用。
复合赋值通常先实现，再复用到普通二元运算：

8.2 四种命名类型转换

本节从「static_cast」「dynamic_cast」和「const_cast」等方面说明四种命名类型转换。
8.2.1 static_cast
用于具有明确语言关系的转换，例如数值转换、枚举转换和继承层次中的受控转换：
数值窄化可能丢失信息，static_cast 只让转换意图更明确，不会自动保证安全。
8.2.2 dynamic_cast
用于多态继承体系中的运行时类型检查：
指针转换失败返回 nullptr；引用转换失败抛出 std::bad_cast。向下转换要求基类具有多态能力，通常至少包含一个虚函数。
8.2.3 const_cast
用于增加或移除 const、volatile 限定：
如果原对象本身确实是常量，随后通过移除限定的指针修改它会导致未定义行为。const_cast 主要用于兼容设计不合理的旧接口，不应作为常规修改手段。
8.2.4 reinterpret_cast
用于底层地址或表示形式相关转换：
这种转换绕过大部分类型系统保护，只适合硬件接口、序列化底层实现和平台相关代码。转换成功不代表目标访问一定满足对齐、别名和生命周期规则。

8.3 隐式转换与 explicit

单参数构造函数和转换运算符可能参与隐式转换：
explicit 要求调用者明确表达转换意图：
接口边界上的隐式转换越多，重载决议和错误定位越困难。自定义数值包装、ID 类型和资源句柄通常适合使用 explicit。

9. 模板与泛型编程

本章从「函数模板」「类模板」和「特化与重载」等方面说明模板与泛型编程。

9.1 函数模板

函数模板描述一组适用于不同类型的通用操作：
编译器根据调用参数实例化具体函数：
模板能够编译不代表所有类型都满足语义要求。上面的 Max 要求类型支持 < 比较，并且返回引用的对象生命周期必须覆盖调用结果的使用范围。

9.2 类模板

使用方式：
模板定义通常放在头文件中，因为实例化发生在使用位置。只有显式实例化等特殊方案能够把部分模板实现移到源文件。

9.3 特化与重载

当通用模板不适合某类类型时，可以使用：
  • 函数重载；
  • 类模板偏特化；
  • 类模板全特化；
  • if constexpr；
  • C++20 Concepts 和 requires。
函数模板通常优先通过重载表达特殊行为，类模板才使用偏特化组织不同类型族。

9.4 if constexpr

C++17 的 if constexpr 可以根据编译期条件选择分支：
未选中的分支不会参与当前模板实例的完整语义检查，因此适合处理不同类型类别的编译期分支。

9.5 泛型代码的约束

泛型函数应说明类型必须满足的操作和语义。C++20 可以使用 Concept 表达约束：
没有使用 Concept 时，也应通过清晰命名、静态断言和文档说明模板要求，避免把复杂错误推迟到深层实例化信息中。

10. STL 容器、迭代器与算法

10.1 STL 的组成

标准模板库的核心部分包括：
  1. 容器：保存数据，例如 vector、list、map。
  1. 迭代器：描述访问范围的位置和遍历能力。
  1. 算法：对迭代器范围执行查找、排序、变换等操作。
  1. 函数对象与 Lambda：为算法提供比较、筛选和转换规则。
  1. 容器适配器：在已有容器上提供栈、队列和优先队列接口。
典型调用形式：
算法不直接依赖某个具体容器，而是依赖迭代器能力。std::sort 需要随机访问迭代器，因此可用于 vector 和 deque，不能直接用于 list；list 提供自己的成员函数 sort()。

10.2 顺序容器

容器
主要特点
典型操作复杂度
vector
连续内存，缓存局部性好，支持随机访问
下标 O(1)；尾部追加均摊 O(1)；中间插删 O(n)
deque
分段连续，支持随机访问和两端操作
随机访问 O(1)；两端插删通常 O(1)
list
双向链表，不支持随机访问
已知位置插删 O(1)；查找位置 O(n)
array
固定长度，元素直接存储在对象内部
随机访问 O(1)
多数需要动态数组的场景优先使用 vector。只有频繁在两端插删或确实需要稳定节点地址时，再考虑 deque、list 等其他容器。
10.2.1 vector 的容量
reserve 只调整容量，不改变 size。resize 会改变元素数量，并构造或销毁元素。
扩容需要申请新内存并移动或复制已有元素，因此单次 push_back 可能为 O(n)，连续追加的均摊复杂度为 O(1)。

10.3 关联容器

本节从「有序关联容器」和「无序关联容器」两方面说明关联容器。
10.3.1 有序关联容器
set、map、multiset 和 multimap 按比较规则维护顺序，常见实现基于平衡树：
查找、插入和删除通常为 O(log n)，并支持有序遍历和范围查询。
10.3.2 无序关联容器
unordered_set 和 unordered_map 基于哈希结构：
查找、插入和删除的平均复杂度通常为 O(1)；冲突严重时，最坏情况可能退化。哈希容器不维护键的排序关系。

10.4 容器适配器

本节从「stack」「queue」和「priority_queue」等方面说明容器适配器。
10.4.1 stack
后进先出：
10.4.2 queue
先进先出：
10.4.3 priority_queue
默认大顶堆，top() 返回最大元素：
小顶堆写法：
top 为 O(1)，push 和 pop 通常为 O(log n)。

10.5 迭代器失效

容器修改可能使现有迭代器、指针和引用失效：
  • vector 重新分配容量时，指向元素的迭代器、指针和引用全部失效；
  • vector 在中间插入或删除时，操作位置及其后的迭代器通常失效；
  • list 插入通常不影响其他节点的迭代器，删除只使被删除节点失效；
  • 无序容器发生重新哈希时，迭代器会失效。
删除遍历中的元素时，应使用容器返回的新迭代器：

10.6 常用算法

本节从「查找与判断」「排序」和「变换」等方面说明常用算法。
10.6.1 查找与判断
10.6.2 排序
比较函数必须满足严格弱序关系。不要使用 <= 代替 <，否则排序算法的行为可能不符合要求。
10.6.3 变换

10.7 Lambda 表达式

常见捕获形式：
  • [value]：按值捕获；
  • [&value]：按引用捕获；
  • [=]：默认按值捕获当前作用域变量；
  • [&]：默认按引用捕获；
  • [this]：捕获当前对象指针。
异步任务或延迟回调按引用捕获局部变量时，需要确认回调执行时变量仍然存在。生命周期无法保证时，按值捕获所需数据，或使用明确的共享所有权方案。

10.8 std::tuple

std::tuple 是固定大小的异构值集合，可看作 std::pair 的推广。
常见操作：
适用场景：
  • 函数临时返回多个不同类型值；
  • 组合键；
  • 泛型编程。
当字段含义稳定且业务语义明显时，定义具名 struct 通常比 tuple 更易读。
std::tuple 示例已使用 C++17 和 -Wall -Wextra -Wpedantic -Werror 编译运行通过。

11. 异常处理与文件 I/O

本章从「异常处理流程」「异常安全保证」和「noexcept」等方面说明异常处理与文件 I/O。

11.1 异常处理流程

异常用于报告当前函数无法在本层正常处理的错误：
调用者捕获异常：
异常通常按值抛出、按常量引用捕获。异常传播过程中，已经构造完成的局部对象会依次析构，这也是 RAII 能够保证清理的基础。
异常适合表示无法在当前层继续完成操作的错误，不应代替普通条件分支或高频控制流程。

11.2 异常安全保证

常见异常安全级别：
  1. 无泄漏保证：失败时至少不会泄漏资源，对象仍可安全销毁。
  1. 基本保证：失败后对象保持有效状态，但值可能发生变化。
  1. 强保证：失败后操作效果等同于没有发生。
  1. 不抛出保证：操作承诺不会让异常逃逸。
赋值或批量更新需要强保证时，可以先在临时对象中完成操作，成功后再交换结果。

11.3 noexcept

noexcept 表示函数承诺不让异常传播到调用者：
标准库容器在重新分配时，通常更愿意使用不会抛异常的移动构造函数。若异常逃出 noexcept 函数，程序会调用 std::terminate。
析构函数和资源释放操作通常不应抛出异常。清理阶段抛出第二个异常可能直接终止程序。

11.4 文件输入输出

本节从「写入文件」和「读取文件」两方面说明文件输入输出。
11.4.1 写入文件
11.4.2 读取文件
流对象离开作用域时自动关闭文件。打开成功不代表后续读写一定成功，读取格式、写入状态和磁盘错误仍需要检查。

12. 项目中的使用原则

本章从「先表达所有权，再选择类型」「优先使用标准库抽象」和「头文件与源文件职责」等方面说明项目中的使用原则。

12.1 先表达所有权，再选择类型

选择指针和对象类型时，先确定谁负责资源生命周期：
  • 值对象：资源属于当前对象，复制后彼此独立；
  • unique_ptr：唯一拥有者；
  • shared_ptr：多个对象共同拥有；
  • weak_ptr：只观察共享对象；
  • 裸指针或引用：通常表示非拥有访问。
所有权关系不清晰时，即使代码暂时能够运行，后续也容易出现泄漏、重复释放和悬空访问。

12.2 优先使用标准库抽象

优先选择：
  • std::string 代替手工字符缓冲区；
  • std::vector 代替动态数组；
  • 智能指针代替直接拥有资源的裸指针；
  • 标准算法代替重复手写循环；
  • RAII 对象代替成对出现的手工申请和释放。
标准库不能消除所有错误，但能够把常见资源管理规则封装进类型系统和对象生命周期中。

12.3 头文件与源文件职责

头文件适合保存：
  • 类型声明；
  • 函数声明；
  • 模板定义；
  • 必须内联的短函数；
  • 编译期常量和接口约束。
源文件适合保存：
  • 非模板函数定义；
  • 具体实现细节；
  • 只在当前模块使用的辅助函数和对象。
头文件应具有包含保护：
或者使用传统宏保护。头文件中避免定义非 inline 的普通全局变量和函数，否则多个翻译单元包含后可能违反单一定义规则。

12.4 编译器警告与运行期检查

开发阶段应开启较严格的编译器警告，并把警告作为潜在缺陷处理。GCC 和 Clang 项目常用：
AddressSanitizer、UndefinedBehaviorSanitizer 等工具可以发现越界访问、释放后使用、部分内存泄漏和未定义行为。它们不能替代代码审查，但能显著缩短底层错误的定位时间。

13. 数值表示和常见应用

本章从「二进制、八进制与十六进制字面量」「IEEE 754 浮点表示」和「文本文件与二进制文件」等方面说明数值表示和常见应用。

13.1 二进制、八进制与十六进制字面量

C++ 可以直接书写不同进制的整数字面量：
这些变量保存的数值相同，区别只在源代码中的表示方式。输出格式可以通过 std::dec、std::oct 和 std::hex 控制。

13.2 IEEE 754 浮点表示

常见的 float 和 double 使用 IEEE 754 浮点格式。浮点数由符号位、指数和尾数组成，因此很多十进制小数无法被二进制精确表示。比较计算结果时应使用允许误差，而不是直接依赖 ==。

13.3 文本文件与二进制文件

文本模式保存字符表示，便于阅读和跨工具查看；二进制模式按字节保存数据，体积和解析成本通常更低，但必须明确字段布局、字节序和版本。直接写入结构体内存会受到对齐和填充影响，不适合作为稳定文件格式。

13.4 位运算

位运算包括按位与 &、按位或 |、按位异或 ^、按位取反 ~、左移 << 和右移 >>。异或满足“相同为 0，不同为 1”，常用于开关位、掩码和成对抵消问题。

13.5 蛇形填数

蛇形填数可以按“方向数组 + 边界检查 + 已访问标记”实现。每次尝试沿当前方向前进；越界或遇到已填位置时顺时针切换方向，直到填满矩阵。

13.6 平闰年判断

公历闰年的判断条件是：年份能被 400 整除，或能被 4 整除但不能被 100 整除。

14. 总结

现代 C++ 的重点不只是记住语法，而是明确对象生命周期、所有权、资源释放和接口边界。项目中应优先使用 RAII、标准容器、智能指针和类型安全的接口，再根据性能证据决定是否采用更底层的实现。

15. 参考资料

]]>