指针操作位图更高效因可直接对齐访问整字并用单条CPU指令批量处理，而vector的位代理对象导致额外开销；用uint8_t*时位索引拆为byte_idx=bit_idx>>3、bit_offset=bit_idx&7，掩码为1U
为什么用指针操作位图比 vector 更高效
因为 vector 是特化容器，底层按位存储但接口模拟布尔值，每次 operator[] 都要掩码+移位+读字节+返回代理对象，无法取地址、不支持指针算术，编译器也难优化。而裸指针 + 原生数组可直接对齐访问整字（如 uint32_t*），批量置位/清零/测试能用单条 CPU 指令（如 AND, OR, BTS）或向量化指令加速。
关键点：位图本质是「大块连续内存的位寻址」，指针让你控制字节偏移和位偏移两个维度，vector 把这两层封装掉了，反而成了瓶颈。
如何用 uint8_t* 实现安全、可移植的位索引计算
位图大小通常按字节对齐分配，但业务逻辑按「位序号」操作（如第 1000 位）。必须把位号拆成「字节下标 + 位内偏移」：
-
byte_idx = bit_idx / 8→ 等价于bit_idx >> 3 -
bit_offset = bit_idx % 8→ 等价于bit_idx & 7 - 对应掩码为
1U （注意用U后缀避免符号扩展）
示例：设置第 1000 位
bit_idx
- 起始位号
L必须是 64 的倍数（即L % 64 == 0），否则首尾需退化为字节级操作 - 内存必须按 8 字节对齐（用
aligned_alloc(8, size)或std::aligned_alloc分配）
示例：清零从第 192 位开始的 128 位（正好 2 个 uint64_t）
uint64_t* bmp64 = static_cast<uint64_t>(aligned_alloc(8, n_bytes)); size_t word_start = 192 / 64; // = 3 bmp64[word_start] = 0; bmp64[word_start + 1] = 0;</uint64_t>
性能影响：现代 x86-64 上，对齐的 mov 写 8 字节几乎无延迟；若未对齐，可能触发总线锁或拆分成多次访问，速度跌 3–5 倍。
释放时必须用原始分配方式，且不能混用 delete[] 和 free
指针指向的内存来自哪，就用对应的释放方式——这是 C++ 指针管理最易翻车的地方：
- 用
new uint8_t[n]分配 → 必须用delete[] ptr - 用
malloc或aligned_alloc分配 → 必须用free(ptr) - 用
std::allocator→ 必须用.allocate() .deallocate()
错误示例：auto p = static_cast → 未定义行为，大概率 crash。
建议：封装成 RAII 类，构造时记下分配方式，析构时自动 dispatch；或者统一用 std::unique_ptr 配自定义 deleter。
真正麻烦的不是怎么写，而是多人协作时有人改了分配方式却忘了同步释放逻辑——这种 bug 往往只在特定内存布局下偶发，调试成本极高。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
