可以用“and”、“or”等代替“&&”、“||”吗？

Question

我已经习惯了 C++ 中的and和or关键字。我一直使用它们，并且输入它们对我来说又快又舒服。 一旦我听说这些别名是非标准的并且可能不适用于所有编译器。 但我不确定，我真的不知道这是不是真的。
让我们假设我把我的代码给别人，他编译它会有问题吗？
当我使用and or代替&&时可以吗|| ？ 还是这些关键词真的不规范？
PSI 使用 MinGW 编译器。

Answer 1

它们实际上是C ++中的标准，正如ISO 14882：2003 C ++标准2.5 / 2所定义的那样（实际上，正如1998年版标准所定义的那样）。 请注意，它们内置于语言本身，并不要求您包含某种类型的头文件。

但是，它们很少使用，我还没有看到实际使用替代令牌的生产代码。 替代令牌首先存在的唯一原因是因为某些键盘上的这些字符（特别是非QWERTY键盘）要么不存在要么笨拙要键入。 它仍然是向后兼容性的标准。

即使它们是标准的，我强烈建议您不要使用它们。 替代标记需要输入更多字符，QWERTY键盘布局已经具有输入C ++代码所需的所有字符，而无需使用替代标记。 此外，他们很可能会对您的代码感到困惑。

2.5 / 2替代代币

在语言的所有方面，除了拼写之外，每个备选令牌的行为分别与其主令牌相同。 表2中定义了替代令牌集。

Table 2 - alternative tokens
+--------------+-----------+
| Alternative  |  Primary  |
+--------------+-----------+
|    <%        |    {      |
|    %>        |    }      |
|    <:        |    [      |
|    :>        |    ]      |
|    %:        |    #      |
|    %:%:      |    ##     |
|    and       |    &&     |
|    bitor     |    |      |
|    or        |    ||     |
|    xor       |    ^      |
|    compl     |    ~      |
|    bitand    |    &      |
|    and_eq    |    &=     |
|    or_eq     |    |=     |
|    xor_eq    |    ^=     |
|    not       |    !      |
|    not_eq    |    !=     |
+--------------+-----------+

Answer 2

这些关键字是标准的，并在标准的第2.5节中描述。 表2是这些“替代令牌”的表格。 您可以随心所欲地使用它们，即使每个人都会恨你。

Answer 3

它们是新c ++ 0x标准的标准配置。 最新的现代编译器应该认识到它们，尽管我认为它们还没有义务。 无论你的船是什么漂浮，我都认为。

Answer 4

它们是标准的C ++，但是对于较旧的编译器，可能还有MSVC 10.0（我还没有检查过），你可能需要包含一个特殊的标题，[isosomethingsomething.h]

干杯和hth。，

Answer 5

我总是弄乱^（xor）和〜（两个补码）运算符。 对于替代令牌（我认为应该是主要的），毫无疑问他们做了什么，是的，我同意以前的海报，文本的更具描述性。

使用有向图有另一种可能的混乱，有可能忘记||，&&中的一个字符会导致细微的错误和奇怪的行为。 对于文本操作员来说，犯这样的错误要困难得多。

我相信我上面提到的是提高代码安全性和清晰度的真正有效论据。 在我看来，大多数C ++程序员应该尝试习惯于文本操作符，而不是旧的神秘操作符。

我很惊讶很少有程序员了解它们。 这些操作员应该在我看来很久以前就已经接管了。

Answer 6

哇，我多年来一直在使用和查看许多C ++代码示例..直到现在，才知道这些，所以我猜这意味着大多数人都不使用它们。 因此，为了保持一致性（如果您计划在小组项目中工作等），最好养成使用&&和||的习惯。

Answer 7

它在语法上是有效的，因为这些是必需的替代标记。

在语言的所有方面，每个替代标记的行为分别与其主要标记相同，除了它的拼写。

但是，一些标记不仅仅用于逻辑或按位运算符。 因此，人们可以看到特质：

auto& foo(auto and T) { // C++20 forwarding reference
    return T;
} 

甚至

auto& foo(auto bitand T) { // lvalue reference
    return T;
} 

这会让一个人挠头一阵子。

Answer 8

显然，在向后兼容性方面，“和/或”关键字不是问题。 我相信它们是更新的标准。 只是老程序员不理解某些菜鸟可能必须能够读取代码并且不想查找&&的含义。 然后，如果任何IT部门值得它的盐，它将使程序员符合公司的标准！ 这是我的信念所以（和/或）是面向未来的未来主义和真实可能的标准。 &&是向后兼容的不是（双关语）（和/或）。

Answer 9

ISO / IEC 14882：1998标准（原始C ++标准）第2.5节说：

§2.5替代令牌[lex.digraph]

1为某些运营商和标点符号提供了替代的令牌表示^16） 。

2在语言的所有方面，每个备用令牌的行为分别与其主令牌相同，但拼写除外^17） 。 表2中定义了替代令牌集。

^16）这些包括“有向图”和其他保留字。 术语“有向图”（由两个字符组成的标记）并不是完全描述性的，因为备选预处理标记之一是％：％：当然，几个主要标记包含两个字符。 尽管如此，那些不是词汇关键词的替代标记通俗地称为“有向图”。

^17）因此[和<：的“字符串化”值（16.3.2）将不同，保持源拼写，但令牌可以自由地互换。

Table 2—alternative tokens
_______________________________________________________________________________
    alternative  primary  |  alternative  primary  |  alternative  primary
     <%            {      |     and          &&    |    and_eq       &=
     %>            }      |    bitor         |     |    or_eq        |=
     <:            [      |     or           ||    |    xor_eq       ^=
     :>            ]      |     xor          ^     |     not         !
     %:            #      |    compl         ~     |    not_eq       !=
     %:%:          ##     |    bitand        &     |
_______________________________________________________________________________

没有讨论'如果你包含一些标题'（虽然在C中，你需要#include <iso646.h> ）。 任何不支持关键字或有向图的实现都不符合C ++标准的1998版，更不用说更高版本了。