17370845950

最直接判断奇偶的方式是用 % 运算符：n % 2 == 0 判偶数，n % 2 != 0 判奇数；它语义清晰、对有符号整数行为确定，且编译器会优化为位运算，性能与 n & 1 等价。

用 % 运算符判断奇偶是最直接的方式

绝大多数场景下，n % 2 == 0 就是判断偶数、n % 2 == 1（或 != 0）判断奇数的标准写法。它语义清晰、可读性强，且对有符号整数（int、long 等）行为确定：C++ 标准规定，当被除数为负时，% 的余数符号与被除数一致，所以 -3 % 2 是 -1，-4 % 2 是 0，仍能正确区分奇偶。

注意点：

• 不要写成 n % 2 == -1 来判断奇数——虽然对负奇数成立

  

  ，但会漏掉正奇数（如 3 % 2 == 1），应统一用 n % 2 != 0
• % 对浮点数不合法，必须用于整型；若变量是 double，先转 int 要小心截断误差
• 编译器对 % 2 通常会自动优化为位运算，实际性能和位运算是等价的（见下条）

用 & 位运算判断只适用于无符号或非负整数

表达式 n & 1 的结果是 1（真）表示奇数，0（假）表示偶数。原理是二进制最低位决定奇偶：偶数末位必为 0，奇数必为 1。

但这里有个关键限制：

• 对 unsigned int、size_t 等无符号类型，n & 1 安全可靠
• 对 int 等有符号类型，若 n 为负，在二进制补码表示下 n & 1 依然能正确返回 0 或 1（因为补码的最低位定义不变），所以实践中也常可用
• 真正危险的是：如果 n 是 char 或 short，参与 & 时会整型提升（promoted）为 int，但只要原值在范围内，结果不受影响

所以效率上，n & 1 和 n % 2 在现代编译器（如 GCC/Clang 启用 -O2）下生成的汇编指令几乎完全相同——编译器早就把 % 2 优化成了 and 指令。手动写 & 1 并不会更快，只是少打几个字符。

什么时候 & 1 可能出错？

问题不在运算本身，而在类型隐式转换和边界理解偏差：

• 若 n 是 bool 类型，n & 1 永远是 n 自身（因为 true 提升为 1，false 为 0），看似“工作”，但语义错乱——bool 本就不该被当作数值奇偶判断
• 若 n 是用户自定义类型并重载了 &，行为完全不可控；而 % 通常未被重载，更安全
• 最隐蔽的坑：std::vector::reference 是代理类型，v[i] & 1 可能触发未定义行为或编译失败，而 v[i] % 2 直接报错，反而更容易暴露问题

别为“位运算更快”过早优化

除非你在写嵌入式裸机代码、或对每纳秒都敏感的 HPC 内核循环，否则没必要纠结这个。真实瓶颈从来不在这里：

• 分支预测失败（比如在随机奇偶混合的数据上频繁 if (n & 1)）比运算本身耗时多得多
• 缓存未命中、内存访问模式、函数调用开销，都比 & 1 vs % 2 的差异大几个数量级
• 可读性优先：团队里新来的同事看到 n & 1 要停顿半秒反应，看到 n % 2 == 0 一眼就懂

真正值得花时间的地方，是确认你的数据类型是否真的需要奇偶判断、是否可能为空、是否涉及线程安全——这些地方出的 bug，远比选哪个运算符难查得多。