为什么C/C++中没有||=运算符？
可能的重复：
&&= 和 ||= 运算符
请参阅标题。这个问题可以扩展到包括所有逻辑+赋值运算符。 澄清一下：我不是在谈论 |= 运算符。
另一个例子：&&=
谢谢。
例子：
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();
Possible Duplicates:
&&= and ||= operators
See title. This question may be expanded to include all logical+assignment operators.
To clarify: I am not talking about |= operator.
Another example: &&=
Thanks.
Example:
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();
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
据猜测，因为它们只对布尔值有意义，而布尔值迟到了
即使布尔值一开始就存在，这些运算符的用途也有限，因为没有副作用，它们将与
| 相同。 =和&=带有布尔操作数，因此唯一的用途是捕获意外传入的非布尔值。如果建议的运算符也是短路的（并非不合理，因为
||和&&用于内置类型），那么您还有其他理由使用它们在存在副作用的情况下。我能想到允许它们的唯一可能的原因是它是否显着简化了语言的解析/编译，但是考虑到它们对于非 bool 类型没有意义，情况可能并非如此。
最终它们不在语言中，因为没有人足够关心将它们放入语言中，因此我们可以得出结论，这些理由都不足以保证提交提案、将其纳入标准和实现功能的成本。
At a guess, as they would only make sense for bools, which were late to the party
Even if bools had been around at the start these operators would be of limited use, as without side-effects they would be identical to
|=and&=with boolean operands, so the only use would be trapping passing a non-bool in by accident.If the proposed operators are also short-circuiting (not unreasonable as
||and&&are for in-built types) then you also have an additional justification for them in the presence of side effects.The only other possible reason I can think of for allowing them would be if it significantly simplified parsing/compiling the language, however that is likely not the case given that they don't make sense for non-bool types.
Ultimately they are not in the language because no one has cared enough to put them in the language, thus we can conclude that none of these justifications is sufficient to warrant the cost of submitting a proposal, getting it into the standard and implementing the feature.
因为它们没有意义。
x op= y的定义是x = x op y，除了x 仅计算一次。这对于将每个操作数（如果对其求值）转换为 bool 的短路运算符意味着什么？||=的等价物可能是这样的：这肯定与其他
op=的解释不同。Because they wouldn't make sense. The definition of
x op= yisx = x op y, except thatxis only evaluated once. What does this mean with a short circuited operator, which converts each of its operands (if it evaluates them) tobool? The equivalent of||=might be something like:which is certainly different from the interpretation of other
op=.没有很好的逻辑原因......只是功能的历史压力。
逻辑运算符通常不能作为单个 CPU 操作码使用，因此它们不像按位运算符那样便宜或基本。逻辑异或也很好，也许
^^，然后^^=。尽管如此，运算符的激增使得创建具有内置样式语义的嵌入式用户定义类型变得越来越困难，而且在现实世界中几乎没有什么好处。我仍然希望看到它们 - 这些运算符确实存在于其他一些语言中，例如 Ruby，而且我发现它们很方便且富有表现力。
No good logical reason... just historical pressures for features.
Logical operators aren't normally available as single CPU opcodes, so they're not as cheap or fundamental as their bitwise counterparts. A logical XOR would be nice too, perhaps
^^, then^^=.Still, a proliferation of operators makes it increasingly painful to create drop-in user-defined types with builtin-style semantics, and there's little real-world gain. I'd still like to see them - these operators do exist in some other languages, like Ruby, and I've found them convenient and expressive.
因为他们的作案手法有很大不同。
查看签名：
复合运算符存在于返回相同类型参数的运算符中，
&&和||运算符返回一个布尔值（或者至少是预期），因此创建复合版本没有意义，除了仅布尔。Because their modus operandi is widely different.
Look at the signatures:
Compounds operators exist for operators that return the same type of argument, the
&&and||operators return a boolean (or at least, are expected to), and therefore it does not make sense to create a compound version, except perhaps for booleans only.