Адрес строкового литерала в единицах перевода

В C и C программисты часто используют строковые литералы для различных целей. Возникает общий вопрос: достоверно ли предполагать, что один и тот же строковый литерал в разных единицах трансляции будет иметь один и тот же адрес памяти?

Стандарт C/C

С99 и проекты стандартов C специально оставляют эту тему неуточненной. В разделе 6.4.5 проекта стандарта C99 говорится: «Неизвестно, различны ли эти массивы [строковые литералы], при условии, что их элементы имеют соответствующие значения». Это означает, что компилятор волен решать, объединять строковые литералы или нет.

Реализации компилятора

На практике разные компиляторы по-разному ведут себя в отношении объединения строковых литералов.

• GCC: Поддерживает объединение строковых литералов между модулями компиляции с помощью флага -fmerge-constants. Это поведение можно отключить с помощью -fno-merge-constants.
• Visual Studio: Включает параметр (/GF) для объединения строковых литералов в пул.
• Другое компиляторы: Может поддерживать или не поддерживать объединение строковых литералов в пул, и это зависит от реализации.

Обоснование отсутствия требований

Обоснование отсутствия требований отсутствие требования к объединению строковых литералов в стандарте C связано с разнообразием компиляторов и сред выполнения в то время. Некоторые реализации хранили строковые литералы в ПЗУ, тогда как другие хранили их в записываемых разделах данных. Чтобы обеспечить переносимость, было сочтено лучшим не указывать какое-либо конкретное поведение.

Практические соображения

В общем, полагаться на строковые литералы, имеющие одинаковые значения, непереносимо. адрес памяти между единицами трансляции. Однако в пределах одной и той же единицы трансляции поведение, скорее всего, будет согласованным, поскольку компилятор имеет больший контроль над оптимизацией.

Заключение

Адрес памяти Строковый литерал — это деталь реализации, и нельзя полагаться на то, что он останется согласованным между единицами перевода. Важно осознавать этот факт и писать код, независимый от таких деталей реализации.