6

所以看起来所有这些：http ://www.cplusplus.com/reference/clibrary/ciso646/是 c++ 中的关键字。

我的问题是。这是 c++ 标准的一部分吗？

我可以依靠它来获得主要编译器的支持吗？我知道 gcc 确实支持这些关键字。

最后，也许这更像是一个偏好或风格问题，但是使用关键字比标准运算符（！、！=、&& ...等）有什么优势吗？

4

5 回答 5

11

我的问题是。这是 c++ 标准的一部分吗？

是的。

我可以依靠它来获得主要编译器的支持吗？

是的。但是默认情况下 MSVC 不支持此功能，您需要将选项传递给它/permissive-（或者，尽管这是错误且过时的/Za），它会禁用 Microsoft 语言扩展。无论如何，为几乎所有 C++ 项目启用此选项似乎是个好主意，可惜默认情况下它是关闭的。

但是与标准运算符相比，使用关键字有什么好处吗

一般来说，没有。但是在 , , 的情况下，and许多（尽管可能不是大多数）人发现它更具可读性。我个人建议使用它们。ornot

如果您绝对希望代码在没有/permissive-标志的情况下在 MSVC 上编译#include <ciso646>（这是一个标准头文件，在符合 C++ 实现时为空，但为 MSVC 上的运算符添加了宏）。

于 2012-07-20T16:04:10.907 回答
7

这是 c++ 标准的一部分吗？

是的。请参见 [lex.digraph] 部分中的表格。

与标准运算符相比，使用关键字有什么优势吗？

我的理解是，引入了原始的二合字母（<%而不是{等）是为了让使用简单键盘的人能够编写 C 代码（维基百科证实了这一点）。也许同样的理由也适用于not_eq等。但是 AFAIK，现在没有充分的理由编写这样的东西（除非你在智能手机上编码），尤其是因为 99% 的程序员不知道它是有效的 C++！

于 2012-07-20T16:01:41.130 回答
5

是的，它们受支持。

就您问题的后半部分而言，它们可以产生更具可读性的代码，尤其是在同时处理按位运算符和逻辑运算时，例如：

if( a & 1 == 0 || c | a == 2 );

对比

if( a & 1 == 0 or c | a == 2 );
于 2012-07-20T16:02:44.767 回答
2

它们在标准中，但支持有些不平衡。有经验的程序员发现它们的可读性不如通常的符号（||, &&,!=等），因此除非您只想对不支持它们的编译器供应商发表政治声明，否则最好避免使用它们。

至少在我看来，它们的定义也很差。特别是，它们是根据令牌定义的，而不是逻辑。他们发明替代标记（trigraphs、digraphs 和这些东西）的真正原因是允许在不支持该语言使用的特殊字符的古代终端上使用该语言。添加这些是为了稍微不那么烦人的三字母和有向字母。我猜他们在这方面取得了成功，但他们仍然只是稍微不那么烦人，而不是任何应该选择使用的东西。

让我们考虑几个例子。如果您真的在那些古老的终端之一上，并且您想编写通过引用传递参数的代码代码，您该怎么做？

void foo(T bitand param);

从那里，很明显你将如何通过右值引用传递一个值：

void foo(T and param);

T& param愚蠢而丑陋，但我想至少它解决了关于vs -- 的古老争论，T &param你bitand需要在两边留出空格。作为回报，它具有误导性、混淆性和不可读性。

哦，请注意不要将其拼写为bit_and而不是bitand. 还有一个名为bit_and的东西，但它完全不同——它bitand是一个预处理器标记，而bit_and它是一个定义在<functional>. 使用错误的可能会导致一些相当混乱的编译器错误。

也就是说，我可以想到一种情况，其中and,bitand等可能是合理的。如果（无论出于何种原因）您无法输入代码，而不得不使用听写软件，那么让听写软件输入可能and比&&. 区分bitand和可能更困难bit_and，但后者很少使用，可能不是什么大问题。

概括

对于少数人来说，使用公认的符号输入代码确实很困难，因此他们可以合理地使用基于单词的标记。

For anybody else, even if they personally find and more readable than &&, inflicting such code on others would be about like if I decided to name an addition function biggerate, because I thought that was a cute name for addition when I was five years old. So, if you like them and you're writing code that you're absolutely, positively certain that nobody else will ever read, sure go ahead and have a blast. Otherwise, using them is a poor idea.

于 2012-07-20T16:14:52.663 回答
-2

微软的编译器不支持它们。您可以在此处查看关键字列表。

这只是风格的问题（也许像一些读者坚持的那样提高了可读性）。就个人而言，我看不出用它们代替 && 和 || 有什么好处。等等

于 2012-07-20T16:07:11.460 回答