为什么没有selectC ++ 14位分隔符的空格字符？

从C ++ 14开始，感谢n3781 （本身并不回答这个问题），我们可以编写如下代码：

const int x = 1'234; // one thousand two hundred and thirty four 

目标是改进这样的代码：

 const int y = 100000000; 

并使其更具可读性。

下划线（ _ ）字符在C ++ 11中已经被用户定义的文字所取代，逗号（ , ）也有本地化的问题 – 许多欧洲国家都把这个用作小数点分隔符，并和逗号运算符冲突我真的不知道现实世界的代码可能被允许例如1,234,567被破坏。

无论如何，更好的解决办法似乎是空间的特点：

 const int z = 1 000 000; 

与string文字一样，这些相邻的数字文字标记可以被预处理器连接起来：

 const char x[5] = "a" "bc" "d"; 

相反，我们得到撇号（ ' ），而不是任何我知道作为数字分隔符的书写系统。

有没有理由select撇号而不是简单的空间？

---

_{^†这是令人困惑的，因为所有这些语言在文本中都保留了一个逗号“分开”的句子的概念，这个句子有一段可以“终止”这个句子的句子 – 对我来说，至less，这与一个类似于逗号“分解”数字的整数部分和“终止”它为分数input做好准备。}

Answer 1

有一个先前的论文， n3499 ，告诉我们，虽然比亚尔本人build议空间作为分隔符：

虽然这种方法与一种常见的字体样式相一致，但是却存在一些兼容性问题。

• 它与pp-number的语法不匹配，并且最低限度地要求扩展该语法。
• 更重要的是，当范围[af]中的hex数字跟在一个空格之后时，会有一些句法歧义。 预处理器不知道是否在空格之后开始执行符号replace。
• 这可能会使编辑工具抓住“文字”不太可靠。

我想下面的例子是主要的问题：

 const int x = 0x123 a; 

尽pipe在我看来，这个理由相当薄弱。 我仍然无法想象一个真实世界的例子来打破它。

“编辑工具”的基本原理更糟糕，因为1'234基本上打破了人类已知的每一种语法突出显示（例如Markdown在上述问题本身中使用的突出显示！），并使得更新版本的荧光笔更难以实现。

尽pipe如此，无论好坏，这是导致采用撇号的理由。

Answer 2

不使用空白的显而易见的原因是新的一行也是空白的，C ++对所有的空白进行相同的处理。 另外，我不知道任何接受任意空格的语言作为分隔符。

据推测，可以使用Unicode 0xA0（non-breaking space） – 这是排版时使用最广泛的解决scheme。 然而，我看到了两个问题：首先，它不是基本字符集，其次，它不是视觉上的独特性; 通过在普通编辑器中查看文本，你不能看到它不是一个空间。

除此之外，没有太多的select。 你不能使用逗号，因为这已经是一个合法的标记了（类似于1,234是目前合法的C ++，意思是234）。 而在可能​​以法律forms出现的情况下，例如a[1,234] 。 虽然我不能想象任何实际的代码实际上使用这个，但是有一个基本的规则，就是没有合法的程序，不pipe多么荒谬，都应该默默地改变语义。

类似的考虑意味着_也不能被使用; 如果有#define _234 * 2 ，那么a[1_234]会默默地改变代码的含义。

我不能说我对select'特别满意' ，但它确实有在欧洲大陆使用的优势，至less在某些types的文本中。 （例如，我似乎记得曾经用德语看过它，尽pipe在典型的正文中，德语和大多数其他语言一样，会使用一个点或一个非破坏性的空间，但也许是瑞士德语）。parsing; 序列'1'已经是合法的， '123' 。 所以像1'234这样的东西可能是1 ，然后是一个字符常量的开始; 我不知道你有多远才能作出决定。 没有一个合法的C ++序列，在这个序列中，一个整型常量后面跟着一个字符常量，所以破坏合法代码没有问题，但这意味着词法扫描突然变得非常依赖于上下文。

（关于你的评论：在select小数或千位分隔符时没有任何逻辑，例如十进制分隔符当然不是一个句号，它们只是任意的约定。

Answer 3

从维基 ，我们有一个很好的例子：

 auto floating_point_literal = 0.000'015'3; 

在这里，我们有. 然后如果另一个操作员会被满足，我的眼睛会等待一些可见的东西，比如逗号或什么东西，而不是空白。

所以这里的撇号比空白的要好得多。

随着空白，这将是

 auto floating_point_literal = 0.000 015 3; 

这与撇号的情况不一样。

---

按照阿尔伯特·伦肖 （ Albert Renshaw）的回答 ，我认为这个撇号比轨道上的亮度种族所提出的空间更清楚。

 type a = 1'000'000'000'000'000'544'445'555; type a = 1 000 000 000 000 000 544 445 555; 

空间用于很多事情，比如OP所提到的string连接，不同于撇号，在这种情况下，对于用来分隔数字的人来说，空格是明确的。

当代码行数变多时，我认为这会提高可读性，但是我怀疑这是他们select它的原因。

---

关于空间，可能值得看看这个C的问题 ，它说：

语言不允许int i = 10 000; （整数字面量是一个标记，干预的空白将其分成两个标记），但是通常将初始化程序expression为文字计算的expression式通常几乎没有花费：

int i = 10 * 1000; /* ten thousand */

Answer 4

我确实没有看到实际的意义：

 if (a == 1 1 1 1 1) ... 

所以数字可能会合并而没有真正的歧义，但hex数字呢？

 0 x 1 a B 2 3 

没有办法消除拼写错误（通常我们应该看到一个错误）

Answer 5

我认为这是因为，在编写代码时，如果达到“行”（屏幕宽度）的末尾，会发生自动换行符（或“换行”）。 这将导致你的int分成两半，一半在第一行，第二个在第二行，这样它们在一个word-wrap的情况下都保持在一起。

Answer 6

这与语言如何被parsing有关。 编译器作者很难重写他们的产品来接受空间分隔的文字。

另外，我不认为用空格分隔数字是很常见的。 我已经看到，即使在不同的国家，它总是非空白的字符。