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