首頁猿問跨翻譯單位的字符串文字地址

跨翻譯單位的字符串文字地址

C++ C

RISEBY 2019-11-02 14:36:27

我想問一下跨翻譯單元依靠字符串文字地址是否可移植？即：給定文件foo.c具有對字符串文字的引用"I'm a literal!"，bar.c例如，依賴于其他給定文件是否正確且可移植，例如，相同的字符串文字 "I'm a literal!"將具有相同的內(nèi)存地址？考慮到每個文件都將轉換為單個.o文件。為了更好地說明，請遵循示例代碼：# File foo.c/* ... */const char * x = "I'm a literal!"# File bar.c/* ... */const char * y = "I'm a literal!"# File test.c/* ... */extern const char * x;extern const char * y;assert (x == y); //Is this assertion going to fail?還有一個gcc示例命令行：gcc -c -o foo.o -Wall foo.cgcc -c -o bar.o -Wall bar.cgcc -c -o test.o -Wall test.cgcc -o test foo.o bar.o test.o在同一個翻譯單元中呢？如果字符串文字位于同一翻譯單元中，這是否可靠？

查看完整描述

2 回答

桃花長相依

TA貢獻1860條經(jīng)驗獲得超8個贊

您不能依賴具有相同存儲位置的相同字符串文字，這是一個實現(xiàn)決策。在C99標準草案告訴我們，這是不確定的相同的字符串字面是否是不同的，從部分6.4.5 字符串文字：

如果它們的元素具有適當?shù)闹?，則不確定這些數(shù)組是否不同。如果程序嘗試修改這樣的數(shù)組，則行為是不確定的。

對于C ++，這在草案標準部分的2.14.5 字符串文字中進行了說明，該文字說：

是否定義了所有字符串文字（即存儲在不重疊的對象中）都是實現(xiàn)定義的。嘗試修改字符串文字的效果是不確定的。

編譯器允許池字符串常量，但你必須了解它的編譯器是如何工作的編譯器，因此這不會是便攜，可能會改變。Visual Studio包含用于字符串文字池的選項

在某些情況下，可以合并相同的字符串文字以節(jié)省可執(zhí)行文件中的空間。在字符串文字池中，編譯器使對特定字符串文字的所有引用都指向內(nèi)存中的同一位置，而不是使每個引用都指向字符串文字的單獨實例。要啟用字符串池，請使用/ GF編譯器選項。

請注意，在某些情況下，它確實符合條件。

gcc確實支持池化和跨編譯單元，您可以通過-fmerge-constants啟用它：

嘗試在編譯單元之間合并相同的常量（字符串常量和浮點常量）。

如果匯編器和鏈接器支持，則此選項是優(yōu)化編譯的默認選項。使用-fno-merge-constants禁止此行為。

注意，嘗試的使用以及如果...支持它。

至于至少下不需要的理由字符串常量被合并，我們由此可以看出在字符串文字存檔comp.std.c討論的理由是由于各種各樣的時候實現(xiàn)的：

GCC可能只是一個例子，但不是動機。在ROMmable數(shù)據(jù)中使用字符串文字的部分原因是為了支持ROMming。我隱約記得使用了C的兩個實現(xiàn)（在做出X3J11決定之前），在這些實現(xiàn)中字符串文字被自動合并或存儲在常量數(shù)據(jù)程序部分中?？紤]到現(xiàn)有的各種實踐以及當需要原始UNIX屬性時可以使用的簡便解決方法，似乎最好不要嘗試保證字符串文字的唯一性和可寫性。

反對回復 2019-11-02