文字列リテラルのメモリ アドレスは、C と C の変換単位間で一貫していますか?

変換単位全体の文字列リテラル アドレス

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

C/C 標準

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

コンパイラの実装

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

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

要件が欠如している根拠

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

実際的な考慮事項

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

結論

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

以上が文字列リテラルのメモリ アドレスは、C と C の変換単位間で一貫していますか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。