既然C和C++中曾经有过使用有向图和三元组的原因，有人把它们放在今天写的代码里吗？是否有大量的遗留代码仍在维护中，其中包含这些代码？

(注：这里，"有向图"不是指"有向图"，有向图和三向图都有多种含义，但这里的预期用途是像??=或<:这样的序列，用来代表#和[这样的字符)

我不确定，但您很可能会发现有向图和三角图在IBM大型机环境中被使用。EBCDIC字符集不包括C所需的某些字符。

有向图和三向图(7位ASCII字符集，用重音字母替换某些标点符号字符)的其他理由在今天可能不那么重要。

在这样的环境之外，我怀疑三联图更常被错误使用，而不是故意使用，如：

作为参考，在1989年的ANSI C标准中引入了三角图(该标准基本上成为1990年的ISO C标准)。他们是：

替换发生在源代码的任何地方，包括注释和字符串文本。

有向图是某些标记的交替拼写，不影响注释或文字：

1995年修订的1990年ISO C标准引入了有向图。

有一个建议正在等待C++ 1Z(下一个标准在C++ 1y之后被标准化为希望-C++ 14)，其目的是从标准中删除三联表。他们对另一个未公开的大型代码库进行了案例研究：

Case study

The uses of trigraph-like constructs in one large codebase were
examined. We discovered:

923 instances of an escaped ? in a string literal to avoid trigraph
replacement: string pattern() const { return"foo-????\?-of-?????"; }

4 instances of trigraphs being used deliberately in test code: two in
the test suite for a compiler, the other two in a test suite for
boost's preprocessor library.

0 instances of trigraphs being
deliberately used in production code. Trigraphs continue to pose a
burden on users of C++.

提案说明(从原始提案中粗体强调)：

If trigraphs are removed from the language entirely, an
implementation that wishes to support them can continue to do so: its
implementation-defined mapping from physical source file characters to
the basic source character set can include trigraph translation (and
can even avoid doing so within raw string literals). We do not need
trigraphs in the standard for backwards compatibility.

它们可以用于国际模糊C代码竞赛。

tri和di图的使用不是在今天编写的，它只存在于在非常有限的环境中创建的非常旧的代码中。任何包含三元图的代码，如果您试图在像VS这样的现代编译器上编译它们，通常不会编译，除非您指定一个链接器选项。我知道对于Visual Studio，该选项是"/zc:trigraphs"

它们之所以存在，是因为C++委员会从不发布会破坏遗留代码的更改。不管是好是坏。有一则轶事说，他们的撤职是被提议和支持的，而且被一位IBM代表阻止了。

我知道这是一个古老的问题，但现在可以说这是一个合法的用途：没有实际键盘的触摸屏。例如，如果您通过平板电脑或类似的方式进行任何编码，典型的美国键盘布局不一定以完整的形式提供，诚然，这是非常罕见的，因为它有多么繁琐(三次点击我的分配操作员)。我个人不使用它们，如果可能的话，但它们在没有它们要表示的实际令牌的情况下是有用的。

同样，我真的希望人们在可能的情况下避免这种情况，但这是了解和使用它们的一个原因。