c++oding="utf-8" ?>
std::bitset的&、|、^、~是当前最高效安全的交并补方案，因其将位集拆分为uint64_t块，每块执行单条cpu指令（如and/or/xor/not），10,000位仅需约157条指令，无需逐位循环；前提为位宽是constexpr编译期常量，且避免test()或手写循环。
直接用 std::bitset 的 &、|、^、~ 就是当前最高效且安全的交并补加速方案——前提是位宽为编译期常量，且不滥用 test() 或逐位循环。
std::bitset 交并补为什么快？不是靠“算法”，而是靠 CPU 指令直译
它不遍历每个 bit，而是把整个 bitset 拆成若干个 unsigned long（64 位系统上通常是 uint64_t）块，对每一块执行一条原生 CPU 指令：AND、OR、XOR 或 NOT。10,000 位只需约 157 条指令，而非 10,000 次分支判断。
- 必须用
constexpr size_t N = 10000;定义大小，std::bitset<n></n>才能触发分块优化；运行时变量如int n = 10000; std::bitset<n></n>直接编译失败 -
a & b返回新对象，但底层是 memcpy 级别的整块拷贝，开销远低于手写循环；若在 hot loop 中高频调用，可改用and_inplace类接口避免临时对象 - 内存连续 + 缓存行对齐（64 字节），预取友好；无虚函数、无动态分配、无分支——所有行为在编译期固化
自定义位数组做交并补：对齐、掩码、跳过全零块三件事必须做对
当你用 std::vector<uint64_t></uint64_t> 或裸数组实现动态位数组时，& 和 | 不是“拿来就能用”的操作——错位、越界、未对齐都会导致未定义行为或静默错误。
- 先检查地址对齐：
reinterpret_cast<uint64_t>(ptr)</uint64_t>前，确认uintptr_t(ptr) % alignof(uint64_t) == 0，否则强转会崩 - 总位数非 64 倍数时，最后一块必须掩码：
uint64_t mask = (1ULL ，否则高位脏数据污染结果 - 性能关键路径上别逐字处理：对连续全零块（
data[i] == 0）直接跳过，百万位场景下可减少 30%+ 的指令数 - 不要用
for (int i = 0; i ——<code>test()内部有分支和除法，比直接读块慢 10 倍以上
补集与差集：&^ 运算符在 Go 里很自然，C++ 里得手动模拟
C++ 标准库没提供 &^（AND-NOT）运算符，但差集 A - B 等价于 A & ~B，补集等价于 ~A 后再清除超出长度的高位——这点极易被忽略。
-
~A会翻转所有 64 位，但你的位数组可能只用了低 100 位；必须后处理：result[words-1] &= mask;，否则高位 1 泄漏 - 差集运算不能简单写成
a & ~b就完事——如果a和b长度不同，需按较短者截断，或对齐补零后再算 - Go 的
bitset库用&^是语法糖，底层仍是& ~，C++ 里写成a & (~b)即可，但要注意~b的类型提升问题（推荐显式 cast 到uint64_t）
popcount 和遍历：别用 count() + test()，用内置 ctz + popcnt 指令
交并补之后常要统计结果中 1 的个数（cardinality），或枚举所有置位索引。这时 count() 和 test(i) 是性能黑洞。
-
count()在 libstdc++ 中是 O(n) 扫描，但现代 CPU 支持POPCNT指令；启用-mpopcnt后，std::bitset::count()会自动内联该指令 - 枚举置位索引时，别写
for (i=0; i<size if res.push_back>——改用 <code>__builtin_ctzll(word)或_tzcnt_u64(word)扫描低位 1，配合word &= word - 1清零最低位，复杂度降为 O(k)，k 是 1 的个数 - 使用前确认编译器支持：
gcc/clang加-mbmi -mpopcnt，MSVC 加/arch:AVX2（隐含支持POPCNT和TZCNT）
真正卡住性能的往往不是位运算本身，而是内存访问模式和边界处理——尤其当位数组跨越多个缓存行时，对齐、分块、掩码这三步漏掉任何一环，都可能让理论上的 64 倍加速变成实际更慢。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
