c - 为什么有必要允许等效的字符串文字存储在不同的静态存储位置

Question

我知道 C 标准允许将具有相同内容的字符串文字存储在不同的位置，至少这是我被告知的，以及我从 SO 上的其他帖子中获取的内容，例如this或 this一。然而，令我感到奇怪的是，标准不要求这些文字的位置相等，因为它可以保证更小的可执行文件并大大加快对字符串文字的相等性检查，使它们成为 O(1) 操作而不是 O(n ).

我想知道是什么论据(来自实现者 POV)使允许这些文字的位置不同变得有吸引力。编译器是否进行了任何类型的优化以使比较文字位置无关紧要？我很清楚，如果您将文字与指向包含相同字符串的不同位置的变量进行比较，那么在位置上进行这样的比较是没有用的，但我试图了解制定标准的人如何看待这个.

我能想到您为什么不想这样做的论据，例如当您对标准支持的操作进行基于位置的比较时，您可能会引入细微的错误，但我对我能想到的结果并不完全满意。

我希望你们中的一些人能够阐明这一点。

编辑1:首先感谢您的回答和评论。除此之外，我想对给出的一些答案添加一些想法:

@hvd:我认为这是特定额外优化的问题，而不是每个字符串文字有一个实例的想法。

@Shafik:我认为你的问题让我明白了为什么将此固定下来不允许很多有用的用法。它只能用于仅限于翻译单元范围的代码中。一旦两个具有相同字符串文字的文件被相互独立地编译，它们都将在它们自己的位置包含它们自己的字符串文字。每次将对象与包含相同文字的其他对象组合时，对象都必须使用外部引用或重新编译。

我认为我完全相信 John Bollinger 和 FUZxxl 建议的不太严格的实现规范是可取的，因为仅指定字符串文字在每个翻译单元中只应存在一次所获得的 yield 微乎其微。

Answer 1

除了只是想避免做不必要工作的旧编译器之外，即使在今天，该要求也不一定有用。

假设您有一个包含字符串文字 "a" 和 "ba" 的翻译单元。假设您还有一个优化编译器，它注意到此翻译单元的 "a" 可以优化为 "ba"+1。

现在假设您有另一个翻译单元，其中包含字符串文字 "a" 和 "ca"。然后，同一编译器会将那个翻译单元的“a”优化为“ca”+1。

如果第一个翻译单元的 "a" 必须与第二个翻译单元的 "a" 比较，编译器不能像这样合并字符串，即使这是一个有用的优化以节省空间。 (正如 FUZxxl 在评论中指出的那样，一些链接器会这样做，如果使用了其中一个链接器，则编译器不需要这样做。不过，并非所有链接器都这样做，因此它在编译器中可能仍然是值得优化的.)