为什么 C 和 C++ 中有二合字母？答案

【问题标题】：Why are there digraphs in C and C++?为什么 C 和 C++ 中有二合字母？
【发布时间】：2009-01-11 06:07:20
【问题描述】：

我今天了解到 C99 和 C++ 中有二合字母。以下是一个有效的程序：

%:include <stdio.h>

%:ifndef BUFSIZE
 %:define BUFSIZE  512
%:endif

void copy(char d<::>, const char s<::>, int len)
<%
    while (len-- >= 0)
    <%
        d<:len:> = s<:len:>;
    %>
%>

我的问题是：它们为什么存在？

【问题讨论】：

验证我的翻译？ %: 是 #，是 {}，<: :> 是 []。这是正确的吗？
真正的答案：因为 IBM 大声疾呼，坚持要强加给所有人。
投票重新开放。这个问题比这个更具体（仅关于and 和or）。这个以更有用的形式提出，并有更多的赞成票。编辑：应该是 stackoverflow.com/questions/1234582/… 的副本。
真正的答案：所以你可以写混淆代码:-)

标签： c++ c c99 digraphs

【解决方案1】：

有向图是为没有支持 ISO 646 字符集的键盘的程序员创建的。

http://en.wikipedia.org/wiki/C_trigraph

【讨论】：

我最近发现了this article，它指出 Pascal 中的二合字母的根源不是键盘限制，而是穿孔卡片字符表示限制。是的，Pascal 不是 C 或 C++，但我想你可能会觉得它很有趣。
非 ASCII 键盘不是问题。当然看起来很奇怪，但是... main(int argc,char *argvÄÅ) ä printf("HelloÖn"); å

【解决方案2】：

我相信它们的存在可以追溯到可能性，在某个地方，有人正在使用带有操作系统的编译器，该操作系统的字符集非常陈旧，不一定包含所有字符C 或 C++ 需要表达整个语言。

此外，它还可以在 IOCCC 中提供良好的条目。

【讨论】：

不一定是编译器，Greg。一些大型机 EBCDIC 字符集在方括号中没有一致的字符，这反而会阻塞数组处理。这是编辑器和/或终端仿真器的限制，而不是编译器本身。
我并不是说它只是编译器。我编辑澄清。
不，它与 EBCDIC 无关。这些序列是为了斯堪的纳维亚人，他们使用一些 ASCII 字符作为语言字符（因此键帽和输出中的符号不同）。
提到IOCCC 为我的这个答案增加了重要价值。

【解决方案3】：

我认为这是因为这个星球上的某些键盘可能没有像“#”和“{”这样的键。

【讨论】：

【解决方案4】：

C/C++ 中的二合字母和三合字母来自 CDC6000（60 位）、Univac 1108（36 位）、DECsystem 10 和 20 个系统（36 位）使用的六位字符集的时代，每个系统都使用一个专有的 64 位字符集与 ASA X3.4-1963（现在称为 ANSI X3.4-1963“7 位美国国家信息交换标准代码”）不兼容。最新版本是 ANSI X3.4-1986。

由于这些系统无法代表所有 96 个图形代码点，因此省略了许多。此外，X3.4 与其他国家标准机构（GBR、GER、ITA 等）协调，X3.4 中的代码点被指定为国家替换字符——最明显的例子是英镑的#符号（很明显，因为 # 字符的名称是“井号”，因为它在美国商业中的传统用法 - 在 Twitter 发展之前）和“{”“}”也被指定为国家替换字符。

因此，有向图的引入为那些无法表示字符的计算机系统以及将国家替换字符分配给冲突代码点的数据终端设备提供了一种机制。 Di/Tri-graph 已成为计算历史的古老产物（如今计算机科学中没有教授的主题）。

关于这个主题的详尽论文可以在这里找到：http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.96.678&rep=rep1&type=pdf

【讨论】：