是否有理由在布尔值上使用 &= 而不仅仅是 =

本文关键字：amp 不仅仅是 有理由 布尔值 是否 | 更新日期: 2023-09-27 18:34:31

我今天遇到了一些代码，这些代码正在检查许多错误条件。自始至终都使用单个布尔值，但不是每次都用=重新分配它，而是用一个&=重新分配，从而对布尔值的先前值和新值进行按位的 AND。代码看起来像这样：

bool result = FirstCheck();
Assert(result);
result &= SecondCheck();
Assert(result);
...

现在我很好奇为什么有人会这样做？这在逻辑上等效于重新分配布尔值，如以下可能的分支所示：

    第一次检查失败
  1. (返回 false(，程序在断言时失败，并且永远不会进入第二次检查
  2. FirstCheck通过(返回true(，程序进入SecondCheck。如果 SecondCheck 返回 true，则结果为 true，因为 true&true = true。如果 SecondCheck 返回 false，则结果为 false，因为 true&false = false。

既然没有逻辑上的区别，是否有其他原因&=可能更可取？还是更有可能是一些从未更改过的旧代码的遗物？

编辑：澄清一下，断言始终是活动代码。实际上，我在调查错误时偶然发现了这段代码，因为断言失败了。

是否有理由在布尔值上使用 &= 而不仅仅是 =

是的，原因是您使用单个布尔值来累积多个函数的返回代码。

如果没有 &=，您将在每次调用时用最新函数覆盖返回代码，因此您只会测试最后一个函数是否成功。 使用 &= 如果单个函数返回 false，则从该点开始返回代码将保持 false，因此您知道至少有一个函数失败。

它节省了编写这样的代码

bFirstCheck == fn1();
bSecondCheck == fn2();
bThirdCheck == fn3();
if (bFirstCheck && bSecondCheck && bThirdCheck) {
}

何时可以编写如下代码：

bCheck = fn1();
bCheck &= fn2();
bCheck &= fn3();
if (true == bCheck) {
}

我猜一开始是： 

bool result = FirstCheck();
result &= SecondCheck();
Assert(result);

所以代码正在检查两个结果是否都是积极的，但后来有人在 firstCheck(( 之后添加了 Assert((。

或者这个人可能来自C++背景，并认为按位运算符比逻辑运算符更快。

您假设断言已启用。如果这是使用 Debug.Assert ，则只有在定义了DEBUG条件编译符号的情况下，才会实际调用该方法。

假设稍后使用result(超出断言(，那么当FirstCheck()返回false时会有所不同。

正如其他人所说，Assert可能并不总是活跃的代码。 然后让我们假设第一个和第三个检查返回 true，第二个检查返回 false。 因此，如果你有 

x = FirstCheck()
x = SecondCheck()
x = ThirdCheck()

那么 x 将等于 true。

但是，如果你这样做了

x &= FirstCheck()
x &= SecondCheck()
x &= ThirdCheck()

x 等于假

相关文章：