翻訳単位にわたる文字列リテラル アドレス

C および C では、プログラマはさまざまな目的で文字列リテラルを使用することがよくあります。よくある質問: 異なる翻訳単位の同じ文字列リテラルが同じメモリ アドレスを持つと仮定するのは信頼できますか?

C/C 標準

C99および C ドラフト標準では、特にこのトピックが未指定のままになっています。 C99 ドラフト標準のセクション 6.4.5 には、「要素が適切な値を持っている場合、これらの配列 [文字列リテラル] が個別であるかどうかは未指定です。」と記載されています。これは、文字列リテラルをプールするかどうかをコンパイラが自由に決定できることを意味します。

コンパイラの実装

実際には、コンパイラが異なれば、文字列リテラルのプールに関する動作も異なります。

• GCC: コンパイル単位間の文字列リテラル プーリングをサポートします。 -fmerge-constants フラグ。この動作は、-fno-merge-constants.
• Visual Studio: で無効にできます。文字列リテラル プーリングのオプション (/GF) が含まれています。
• その他コンパイラ: 文字列リテラル プーリングをサポートする場合とサポートしない場合があります。実装固有。

要件がないことの根拠

C 標準で文字列リテラルをプールする必要がない根拠は、次のような多様性によるものです。当時のコンパイラとランタイム環境。一部の実装では文字列リテラルを ROM に保存していましたが、他の実装では文字列リテラルを書き込み可能なデータ セクションに保存していました。移植性を確保するには、特定の動作を強制しないことが最善であると考えられました。

実際的な考慮事項

一般に、同じ文字列リテラルに依存するのは移植性がありません。翻訳単位間のメモリ アドレス。ただし、同じ翻訳単位内では、コンパイラが最適化をより詳細に制御できるため、動作が一貫している可能性が高くなります。

結論

文字列リテラルは実装の詳細であり、翻訳単位間で一貫性を維持することに依存できません。この事実を認識し、そのような実装の詳細に依存しないコードを作成することが重要です。