回答:
元のC言語は、1969年から1972年に設計されたもので、まだ80桁のパンチカードがコンピューティングの大半を占めていました。その設計者は、ASR-33 Teletypeなどの80カラムデバイスを使用しました。これらのデバイスはテキストを自動的にラップしなかったため、ソースコードを80列以内に収めるという真のインセンティブがありました。FortranとCobolには、最終的に自由形式に移行する前に、明示的な継続メカニズムがありました。
Dennis Ritchie(私が推測する)にとっては、文法にあいまいさはなく、コンパイラに隣接するリテラル文字列を連結させるという簡単な手段によって、長いASCII文字列を80列に収めることができることを理解するのは素晴らしいストロークでした。数え切れないほどのCプログラマーがその小さな機能に感謝していました。
機能が有効になったら、なぜ削除されるのですか?それは悲しみを引き起こさず、しばしば便利です。より多くの言語がそれを持っていることを願っています。現在の傾向は、トリプルクォートまたは他の記号を使用して文字列を拡張することですが、Cでのこの機能のシンプルさはこれまでにないものです。
Cには、+
C#やJavaのような特定の文字列連結演算子()はありません。C#またはJavaでは、コンパイラが
"a" + "b"
まるでコードをコンパイルできます
"ab"
ソースコードで書かれていました。ただし、Cには、コンパイラが認識して事前計算できる文字列の連結を記述するための同様に簡単な構文はありません。だから何十年も前のCのデザイナーはそれを選んだ
"a" "b"
とまったく同じことを意味します
"ab"
当然、C ++は同じ規則を継承しました。標準C ++ライブラリは文字列の連結を意味するようにオーバーロード+
しますが、実際にはエラーであるためstd::string
、コンパイラーは合体を試みません"a" + "b"
(2つのconst char *
ポインターを一緒に追加することはできません)。
+
連結を意味するように作られたとしても、連結された文字列がメモリ内のどこにあるかという問題を解決する必要があります。
#define FOO "foo-value"
その後に"FOO's value is " FOO "."