かつてC と C++ でdigraph と trigraphを使用する理由があったことを考えると、今日書かれているコードにそれらを入れる人はいますか? それらを含む、まだメンテナンス中の大量のレガシー コードはありますか?
(注: ここで、「有向グラフ」は「有向グラフ」を意味しません。有向グラフと三重グラフには複数の意味がありますが、ここでの使用目的は、??=
またはのような<:
文字の代わり#
になるシーケンスです[
)
確かなことはわかりませんが、IBM メインフレーム環境で使用されている digraph と trigraph を見つける可能性が最も高いでしょう。EBCDIC文字セットには、C に必要な一部の文字が含まれていません。
digraph と trigraphs のもう 1 つの理由は、一部の句読点をアクセント付きの文字に置き換える 7 ビット ASCII 風の文字セットであり、今日ではおそらく関連性が低くなります。
そのような環境以外では、次のように、トリグラフは意図的にではなく誤って使用されることが多いと思います。
puts("What happened??!");
参考までに、トリグラフは 1989 ANSI C 標準 (実質的に 1990 ISO C 標準になった) で導入されました。彼らです:
??= # ??) ] ??! |
??( [ ??' ^ ??> }
??/ \ ??< { ??- ~
置換は、コメントや文字列リテラルを含め、ソース コードの任意の場所で行われます。
ダイグラフは、特定のトークンの別のスペルであり、コメントやリテラルには影響しません。
<: [ :> ]
<% { %> }
%: # %:%: ##
ダイグラフは、1990 年の ISO C 標準に対する 1995 年の修正によって導入されました。
C++1z (C++1y の次の標準は、願わくば C++14 に標準化される予定です)に対して保留中の提案があり、標準からトライグラフを削除することを目的としています。彼らは、他の方法では公開されていない大規模なコードベースでケース スタディを行いました。
ケーススタディ
1 つの大きなコードベースでのトライグラフのような構造の使用が調べられました。私たちは発見しました:
エスケープされた ? の 923 インスタンス トリグラフの置換を避けるために文字列リテラルで: string pattern() const { return "foo-????\?-of-?????"; }
テスト コードで意図的に使用されているトライグラフの 4 つのインスタンス: コンパイラのテスト スイートで 2 つ、ブーストのプリプロセッサ ライブラリのテスト スイートで他の 2 つ。
実稼働コードで意図的に使用されているトリグラフの 0 インスタンス。Trigraph は、C++ のユーザーに負担を課し続けています。
提案の注記 (元の提案からの大胆な強調):
トリグラフが言語から完全に削除された場合、それらをサポートしたい実装は引き続きそうすることができます: 物理ソース ファイルの文字から基本的なソース文字セットへの実装定義のマッピングには、トリグラフ変換を含めることができます (また、内部でそうすることを避けることさえできます)。生の文字列リテラル)。下位互換性のために、標準ではトライグラフは必要ありません。
トライグラフとダイグラフの使用は、今日では書かれておらず、非常に限られた環境で作成された非常に古いコードにのみ存在します。トリグラフを含むコードは、VS などの最新のコンパイラでコンパイルしようとすると、通常、リンカー オプションを指定しない限りコンパイルされません。Visual Studio の場合、そのオプションは "/Zc:trigraphs" です。
それらが存在する理由は、C++ 委員会がレガシー コードを「壊す」ような変更を決して発行しないためです。良くても悪くても。それらの削除が提案され、サポートされ、IBM の担当者が 1 人で停止したという逸話があります。
これが古い質問であることは承知していますが、最近では間違いなく正当な用途があります。実際のキーボードのないタッチスクリーンです。たとえば、典型的な US キーボード レイアウトは、タブレットなどを介してコーディングを行う場合、必ずしも完全な形で利用できるとは限りません。 . 私は個人的には可能な限りそれらを使用しませんが、それらが表す実際のトークンがない場合に役立ちます。
繰り返しますが、可能な限りこれを避けることを本当に望んでいますが、それはそれらを知って使用する理由の 1 つです。