为什么这个Bug如此狡猾？
直觉背叛：我们直觉上认为 -A 就是 “负的A”，但在位运算中它变成了"A的补码"
测试遗漏：我们测试了正数情况，但对负数的测试不够充分
认知偏差：我们都"知道"补码，但真正用到时却忘了它的存在
你发现下面代码中的问题了吗 ？
// 伪代码：用负数表示反选，正数表示正常选择
bool ShouldSelect(int value, int mask)
{
if (-value & mask == Mathf.Abs(-value))
{
return -value > 0;
}
return false;
}
在C#中，A & B 和 -A & B 的区别主要在于对负数处理的不同。让我通过具体案例来说明：
案例演示
int A = 5; // 二进制: 0000 0101
int B = 3; // 二进制: 0000 0011
// 情况1: A & B
int result1 = A & B; // 5 & 3
Console.WriteLine($"A & B = {result1}"); // 输出: 1
// 情况2: -A & B
int result2 = -A & B; // -5 & 3
Console.WriteLine($"-A & B = {result2}"); // 输出: 3
二进制分析：
A = 5: 0000 0101
B = 3: 0000 0011
A & B: 0000 0001 = 1
-A = -5: 1111 1011 (补码表示)
B = 3: 0000 0011
-A & B: 0000 0011 = 3
更多案例
// 案例2
int A2 = 10; // 1010
int B2 = 6; // 0110
Console.WriteLine($"{A2} & {B2} = {A2 & B2}"); // 输出: 2
Console.WriteLine($"-{A2} & {B2} = {-A2 & B2}"); // 输出: 6
// 案例3 - 负数和负数
int A3 = -3;
int B3 = -5;
Console.WriteLine($"{A3} & {B3} = {A3 & B3}"); // 输出: -7
背后的意义
1. 补码表示法
- 在C#中，整数使用二进制补码表示
- 正数的补码是其本身
- 负数的补码 = 对应正数的二进制取反 + 1
2. 运算本质
A & B：对两个数的实际二进制位进行按位与-A & B：先计算A的补码（得到-A），再与B进行按位与
3. 实际应用场景
// 标志位检查
[Flags]
enum Permissions
{
Read = 1, // 0001
Write = 2, // 0010
Execute = 4 // 0100
}
// 检查权限
Permissions userPermissions = Permissions.Read | Permissions.Write;
// 正确的方式：直接与操作
bool canRead = (userPermissions & Permissions.Read) != 0; // true
// 错误的方式：使用负数（无意义）
bool wrongCheck = (-(int)userPermissions & (int)Permissions.Read) != 0; // 结果不可预测
4. 重要注意事项
// 注意：-A & B 不等于 -(A & B)
int A = 5, B = 3;
Console.WriteLine($"-A & B = {-A & B}"); // 3
Console.WriteLine($"-(A & B) = {-(A & B)}"); // -1
总结
A & B 是直接的按位与运算，结果可预测-A & B 涉及补码转换，结果取决于负数的二进制表示- 在实际编程中，应避免对负数进行无意义的位运算，除非明确理解补码机制
- 位运算通常用于标志位、掩码操作等场景，应保持操作数的明确性和可读性