可能重复：
&&= and ||= operators
见标题。可以扩展此问题以包括所有逻辑+赋值运算符。 澄清：我不是在谈论| =运算符。
另一个例子：＆amp;＆amp; =
感谢。
示例：
bool result = false; // Today result = result || my_test1(); // Do stuff result = result || my_test2(); // In my imagination only... result ||= my_test1(); // Do stuff result ||= my_test2();
答案 0 :(得分：13)
猜测一下，因为他们只对派对迟到的布尔有意义
即使bools一开始就存在，这些运算符的用途也是有限的，因为没有副作用，它们与|=和&=具有布尔操作数相同，所以唯一的用途是意外地诱捕非布尔人。
如果提议的运算符也是短路的（||并且&&对于内置类型而言并非不合理），那么在存在副作用的情况下，您还可以为它们提供额外的理由。
我能想到允许它们的唯一其他可能原因是它是否显着简化了解析/编译语言，但是对于非bool类型而言，它们可能并非如此。
最终他们不会使用语言，因为没有人足够关心语言，因此我们可以得出结论，这些理由中没有一个足以保证提交提案，将其纳入标准并实施功能。
答案 1 :(得分：8)
因为它们没有意义。 x op= y的定义为x = x op y，但x仅评估一次。这对于短路运算符意味着什么，它将每个操作数（如果它评估它们）转换为bool？相当于||=可能类似于：
if ( !x )
x = y;
肯定不同于其他op=的解释。
答案 2 :(得分：3)
没有合理的理由......只是历史上的特征压力。
逻辑运算符通常不能作为单CPU操作码使用，因此它们不像它们的按位对应物那样便宜或基本。逻辑XOR也很好，可能是^^，然后是^^=。
尽管如此，运营商的激增使得使用内置式语义创建插入式用户定义类型变得越来越痛苦，并且几乎没有实际收益。我仍然希望看到它们 - 这些运算符确实存在于其他语言中，比如Ruby，我发现它们方便且富有表现力。
答案 3 :(得分：3)
因为他们的作案手法差异很大。
查看签名：
T operator+(T,T);
T& T::operator+=(T);
T operator*(T,T);
T& T::operator*=(T);
bool operator&&(T,T);
???
对于返回相同类型参数的运算符，存在复合运算符，&&和||运算符返回一个布尔值（或者至少是预期的），因此它没有意义创建一个复合版本，除了仅限布尔。