看起来所有这些：http://www.cplusplus.com/reference/clibrary/ciso646/是c ++中的关键字。
我的问题是。这是c ++标准的一部分吗？
主编译器是否可以依赖此功能？我知道gcc确实支持这些关键字。
最后，也许这更像是一个偏好或风格问题，但使用关键字而非标准运算符（！，！=，＆amp;＆amp; ...等）是否有任何优势？
答案 0 :(得分：10)
我的问题是。这是c ++标准的一部分吗？
是
主要编译器是否可以依赖它？
是。但是默认情况下MSVC不支持此功能，您需要pass it the option /permissive-（或者，虽然这是错误和过时的，/Za），它会禁用Microsoft语言扩展。对于几乎所有C ++项目来说，启用此选项似乎是一个好主意，默认情况下它只是一个耻辱。
但使用关键字而不是标准运算符
是否有任何优势
一般来说，没有。但在and，or，not的情况下，许多人（尽管可能不是大多数人）发现它更具可读性。我个人建议使用它们。
如果您绝对希望代码在没有/permissive-标志的MSVC上编译，#include <ciso646>（这是在遵守C ++实现时为空的标准头，但为MSVC上的运算符添加了宏）。
答案 1 :(得分：7)
这是c ++标准的一部分吗？
是。请参阅[lex.digraph]。
部分中的表格在标准运算符上使用关键字有什么好处吗？
我的理解是引入了原始有向图（<%而不是{等）以允许具有简单键盘的人能够编写C代码（Wikipedia corroborates this）。也许同样的理由适用于not_eq等。但AFAIK，现在没有充分的理由来编写这样的东西（除非你在智能手机上编码），尤其是因为99％的程序员不知道它的有效的C ++！
答案 2 :(得分：5)
是的，他们受到支持。
就问题的后半部分而言，它们可以带来更易读的代码，尤其是在处理按位运算符以及同时处理逻辑运算时，例如：
if( a & 1 == 0 || c | a == 2 );
vs
if( a & 1 == 0 or c | a == 2 );
答案 3 :(得分：1)
他们符合标准，但支持有些不平衡。经验丰富的程序员发现它们的可读性低于通常的符号（||，&&，!=等等。所以，除非您只是想对编译器的供应商做出政治声明。不支持他们，他们最好避免。
答案 4 :(得分：-2)
微软的编译器不支持它们。您可以看到list of keywords here。
这只是一种风格问题（也许是一些读者所坚持的可读性改进）。就个人而言，我认为使用它们代替＆amp;＆amp; amp;和||等