这个维基百科页面将 c++ 定义为“空白独立语言”。虽然与所有语言一样大部分都是正确的,但该规则也有例外。目前我能想到的只有这样一个:
vector<vector<double> >
必须有空格,否则编译器会将 >> 解释为流运算符。周围还有什么。编译一个例外列表会很有趣。
这个维基百科页面将 c++ 定义为“空白独立语言”。虽然与所有语言一样大部分都是正确的,但该规则也有例外。目前我能想到的只有这样一个:
vector<vector<double> >
必须有空格,否则编译器会将 >> 解释为流运算符。周围还有什么。编译一个例外列表会很有趣。
按照该逻辑,您可以使用任何两个字符的词位来为规则生成此类“例外”。例如,+=
并且+ =
会有不同的解释。不过,我不会称它们为例外。在许多情况下,在 C++ 中,“根本没有空格”与“一个或多个空格”完全不同。当有人说 C++ 与空间无关时,他们通常表示 C++ 中的“一个空格”通常与“多个空格”相同。
这反映在语言规范中,该规范声明(参见 2.1/1)在翻译的第 3 阶段允许实现用一个空格字符替换多个空白字符的序列。
解析 C++ 的语法和语义规则确实相当复杂(我试图表现得很好,我认为有人有权说“一团糟”)。这一事实的证明是,多年来,不同的编译器作者只是在争论什么是合法的 C++,什么不是。
例如,在 C++ 中,您可能需要解析无限数量的记号,然后再决定第一个记号的语义是什么(可怕的“最令人头疼的解析规则”,它也经常困扰新手)。
但是,您的反对 IMO 并没有真正的意义……例如,与++
具有不同的含义+ +
,并且在 Pascalbegin
中与beg in
. 这是否使 Pascal 成为一种空间依赖语言?是否有任何与空间无关的语言(brainf*ck 除外)?
关于 C++03 >>
/的唯一问题> >
是打字时的这个错误非常普遍,所以他们决定在语言定义中增加更多的复杂性来解决 C++11 中的这个问题。
一个空格而不是更多空格可以产生影响的情况(区分空间相关语言但在> >
/情况下不起作用的>>
情况)确实很少:
在双引号字符串中(但每个人都想要那个,而且我知道的每一种支持字符串文字的语言都一样)
在单引号内(相同,即使没有多少 C++ 程序员知道单引号内可以有多个字符)
在预处理器指令中,因为它们以行为基础工作(换行符是一个空格,它在那里有所作为)
stefanv 注意到的行继续:要继续单行,您可以在换行符之前放置一个反斜杠,在这种情况下,语言将忽略这两个字符(即使在标识符中间,您也可以这样做,即使典型使用只是为了使长的预处理器宏可读)。如果您在反斜杠之后和换行符之前放置其他空白字符,则无法识别行继续(一些编译器无论如何都会接受它并简单地检查一行的最后一个非空白是否是反斜杠)。也可以使用??/
与反斜杠等效的 trigraph 来指定行继续(任何合理的编译器都应该在 IMO 找到 trigraph 时发出警告,因为它们很可能没有被程序员缩进)。
在单行注释内//
,因为在注释中间向其他空格添加换行符也会有所不同
Like it or not, but macro's are also part of C++ and multi-line macro's should be separated with a backslash followed by EOL, no whitespace should be in between the backslash and the EOL.
Not a big issue, but still a whitespace exception.
set<set<int> >
.' '
." "
.else return x;
, void foo(){}
, 等。这是因为解析器在 c++11 之前的限制,这不再是这种情况。
原因是与运算符 >> 相比,难以将 >> 解析为模板的结尾
虽然 C++03在所有情况下都解释>>
为移位运算符(在流中使用时已被覆盖,但它仍然是移位运算符),但 C++11 中的语言解析器现在将在合理的情况下尝试关闭大括号。