是否可以使用“和”，“或”等代替“＆amp;＆amp;”，“||”？

Question

我已经习惯了C ++中的and和or关键字。我总是使用它们，打字它们对我来说既快又舒服。一旦我听说这些别名是非标准的，可能不适用于所有编译器。但我不确定，我真的不知道这是不是真的 我们假设我给某人代码，他编译时会遇到问题吗？ 当我使用and，or代替&&，||时，它可以吗？或者这些关键字真的不合标准吗？ P.S.I使用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]

欢呼＆amp;第h。，

Answer 5

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

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

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

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

Answer 6

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

Answer 7

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

  

§2.5替代令牌[lex.digraph]

     

为某些操作符和标点符号 ^16）提供了替代标记表示。

     

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

     

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

     

^17）因此[和＆lt ;:的“字符串化”值（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版，更不用说更高版本了。

Answer 8

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