为什么未为C ++ 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;

这些相邻的数字文字标记可以和字符串文字一样由预处理器连接：

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

相反，我们得到撇号（'），我所知道的任何书写系统都没有使用它作为数字分隔符。

是否存在选择撇号而不是简单空格的原因？

_{^†之所以感到莫名其妙，是因为所有这些语言在文本内都保持着逗号的概念，即“分开”原本原子的句子，并用句号“终结”该句子-至少对我而言，这与逗号“分解”数字的整数部分，并用句号“终止”数字以准备小数输入。}

先前有一篇论文n3499，它告诉我们，尽管Bjarne本人建议使用空格作为分隔符：

尽管此方法与一种常见的排版样式一致，但仍存在一些兼容性问题。

• 它与pp-number的语法不匹配，并且至少需要扩展该语法。
• 更重要的是，当[af]范围内的十六进制数字跟随一个空格时，在语法上会有些歧义。预处理器将不知道是否在空格之后开始执行符号替换。
• 可能会使捕获“单词”的编辑工具的可靠性降低。

我想以下示例是指出的主要问题：

const int x = 0x123 a;

尽管在我看来，这个理由还很薄弱。我仍然想不出一个打破现实的例子。

“编辑工具”的原理甚至更糟，因为1'234基本上破坏了人类已知的每个语法突出显示（例如，上述问题本身中Markdown所使用的语法！），并使所述突出显示的更新版本更加难以实现。

不管是好是坏，这都是导致使用撇号的理由。

不使用空格的明显原因是换行符也是空格，并且C ++平等地对待所有空格。另外，我不知道有任何语言接受任意空格作为分隔符。

大概可以使用Unicode 0xA0（不间断空格），它是排版时使用最广泛的解决方案。但是，我看到了两个问题：首先，它不在基本字符集中，其次，在视觉上没有区别。仅通过在普通编辑器中查看文本就看不到它不是空格。

除此之外，没有太多选择。您不能使用逗号，因为它已经是合法令牌（和类似1,234当前合法的C ++，含义为234）。并且在可能以法律代码出现的情况下，例如a[1,234]。尽管我无法想象实际使用此代码的任何实际代码，但有一个基本规则，即无论多么荒谬的法律程序都不应默默更改语义。

类似的考虑也意味着_不能使用。如果有 #define _234 * 2，则a[1_234]则将默默更改代码的含义。

我不能说我对的选择感到特别满意'，但是它确实具有在欧洲大陆使用的优势，至少在某些类型的文本中也是如此。（例如，我似乎记得曾用德语看过它，尽管在典型的运行文本中，德语像大多数其他语言一样会使用点或不间断的空格。但是也许是瑞士德语。）'解析的问题; 该顺序'1'已经是合法的'123'。所以类似的东西1'234可能是1，后跟一个字符常量的开头；我不确定您必须提前多久才能做出决定。没有合法的C ++序列，其中可以在整数常量后跟一个字符常量，因此打破合法代码没有问题，但这意味着词法扫描突然变得非常依赖于上下文。

（关于您的评论：选择十进制或千位分隔符没有逻辑。例如，十进制分隔符肯定不是句号。它们只是任意约定。）

在wiki上，我们有一个很好的例子：

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提到的字符串连接，而不是撇号，在这种情况下，空格使清楚的人用于分隔数字。

当代码行变得很多时，我认为这将提高可读性，但是我怀疑那是他们选择它的原因。

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

该语言不允许int i = 10 000;（整数文字是一个标记，中间的空格将其分成两个标记），但是通过将初始化器表示为一个计算文字的表达式，通常不会产生任何费用：

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

的确，我认为：

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

因此数字可以合并而没有真正的歧义，但是十六进制数字呢？

0 x 1 a B 2 3

这样做无法消除拼写错误（通常我们应该看到一个错误）

我认为这是因为在编写代码时，如果到达“行”（屏幕的宽度）的末尾，则会出现自动换行符（或“自动换行”）。这将导致您的int被分成两半，其中一半将出现在第一行中，后半部分出现在第二行中...这样，如果发生，它们将保持在一起word-wrap。

float floating_point_literal = 0.0000153;   /* C, C++*/

auto floating_point_literal = 0.0000153;    // C++11

auto floating_point_literal = 0.000'015'3;  // C++14

发表评论不会造成伤害：

/*  0. 0000 1530 */ 
float floating_point_literal = 0.00001530; 

二进制字符串可能很难解析：

long bytecode = 0b1111011010011001; /* gcc , clang */  

long bytecode = 0b1111'0110'1001'1001;  //C++14
// 0b 1111 0110 1001 1001  would be better, really.
// It is how humans think.

需要考虑的宏：

#define B(W,X,Y,Z)    (0b##W##X##Y##Z)
#define HEX(W,X,Y,Z)  (0x##W##X##Y##Z)
#define OCT(O)        (0##O)



long z = B(1001, 1001, 1020, 1032 ); 

// result :  long z = (0b1001100110201032);

 long h = OCT( 35); 

// result :  long h  = (035); // 35_oct => 29_dec

 long h = HEX( FF, A6, 3B, D0 ); 

// result :  long h  = (0xFFA6BD0);

它与语言的解析方式有关。对于编译器作者来说，很难重写其产品以接受以空格分隔的文字。

另外，我认为用空格分隔数字并不常见。我已经知道，即使在不同的国家，也总是非空白字符。