隣接する文字列リテラルの連結について


17

CおよびC ++は、隣接する文字列リテラルを単一の文字列リテラルとしてコンパイルします。例えばこれは:

"Some text..." "and more text"

以下と同等です:

"Some text...and more text"

C#やJavaなどの他のCファミリ言語では、これは構文エラーです(完全に問題ありません)。

CおよびC ++がこれを行う理由/歴史的理由は何ですか?

回答:


24

元のC言語は、1969年から1972年に設計されたもので、まだ80桁のパンチカードがコンピューティングの大半を占めていました。その設計者は、ASR-33 Teletypeなどの80カラムデバイスを使用しました。これらのデバイスはテキストを自動的にラップしなかったため、ソースコードを80列以内に収めるという真のインセンティブがありました。FortranとCobolには、最終的に自由形式に移行する前に、明示的な継続メカニズムがありました。

Dennis Ritchie(私が推測する)にとっては、文法にあいまいさはなく、コンパイラに隣接するリテラル文字列を連結させるという簡単な手段によって、長いASCII文字列を80列に収めることができることを理解するのは素晴らしいストロークでした。数え切れないほどのCプログラマーがその小さな機能に感謝していました。

機能が有効になったら、なぜ削除されるのですか?それは悲しみを引き起こさず、しばしば便利です。より多くの言語がそれを持っていることを願っています。現在の傾向は、トリプルクォートまたは他の記号を使用して文字列を拡張することですが、Cでのこの機能のシンプルさはこれまでにないものです。


8
もう1つの理由は、文字列リテラルとして定義されたプリプロセッサマクロの連結を許可することです。たとえば、#define FOO "foo-value"その後に"FOO's value is " FOO "."
Blrfl

3
@Blrfl:そうです。マクロの置換が完了した後に文字列の連結が行われることを理解することが重要です。
david.pfx

7

Cには、+C#やJavaのような特定の文字列連結演算子()はありません。C#またはJavaでは、コンパイラが

"a" + "b"

まるでコードをコンパイルできます

"ab"

ソースコードで書かれていました。ただし、Cには、コンパイラが認識して事前計算できる文字列の連結を記述するための同様に簡単な構文はありません。だから何十年も前のCのデザイナーはそれを選んだ

"a" "b"

とまったく同じことを意味します

"ab"

当然、C ++は同じ規則を継承しました。標準C ++ライブラリは文字列の連結を意味するようにオーバーロード+しますが、実際にはエラーであるためstd::string、コンパイラーは合体を試みません"a" + "b"(2つのconst char *ポインターを一緒に追加することはできません)。


1
Cには特定の文字列型もありません。代わりに、メモリ内の文字へのポインタを選択します。ポインターを追加することはできません。+連結を意味するように作られたとしても、連結された文字列がメモリ内のどこにあるかという問題を解決する必要があります。
Blrfl
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.