逻辑运算符的书面版本
这是我见过的唯一的地方， or在C ++中not被列为实际操作符。 当我在NetBeans中写了一个testing程序的时候，我得到了红色的下划线，就好像有一个语法错误，并认为这个网站是错误的，但是它是错误的，因为它是按照预期编译和运行的。
我可以看到! 被赞成而not但是可读性and ＆ or似乎比他们的语法兄弟更大。 为什么这些版本的逻辑运算符存在，为什么似乎没有人使用它？ 这是真正有效的C ++还是与C语言包含的某种兼容性？
他们起源于头文件<iso646.h>中的C. 当时有些键盘无法input&& （例如）所需的符号，所以头文件中包含了#define ，这可以帮助他们这样做，（在我们的例子中）定义and是&& 。 当然，随着时间的stream逝，这变得不那么习惯了。
在C ++中，它们变成了所谓的备用令牌 。 您不需要在兼容的编译器中包含任何东西来使用这些标记（因此，C标头的C ++版本， <ciso646> ，为空）。 替代标记就像常规标记，除了拼写。 所以在parsing过程中， and && 完全一样，这只是拼写同一个东西的另一种方式。
至于它们的用途：因为它们很less被使用，所以使用它们往往更令人惊讶和困惑，而不是有用的。 我敢肯定，如果这是正常的，他们会更容易阅读，但人们习惯于&&和|| 其他任何东西只是分散注意力。
编辑：我看到了，因为我发布这个，但是，他们的使用非常轻微的增加。 我仍然避免他们。
它们确实存在可用性（键盘/显示器风格中的字符支持）和一般的可读性，但还有另一个原因现在更加明显。 几乎没有任何答案在 这里 ，甚至在这里的主要答案都明白了我们许多人喜欢字符版本超过符号版本的核心原因（以及其他语言使用它们的主要原因）：错误。 这两个词的版本之间的差异是非常明显的。 符号版本之间的差异明显较less，以至于诱发错误的程度相对较大：“x | y”非常不是“x || y”，但是当embedded更大的expression式时，我们中的许多人错过了差异。 这类似于赋值与平等运算符的常见意外混合。 出于这个原因，我放弃了符号版本（这并不容易），赞成单词版本。 由于我们爱旧事物，而不是诱惑臭虫，所以我宁愿让别人做一番双重的事情。
在C ++中，它们是真正的关键字。 在C中，它们是在<iso646.h>定义的macros。 请参阅http://web.archive.org/web/20120123073126/http://www.dinkumware.com/manuals/?manual=compleat&page=iso646.html 。
