2017-09-01 86 views
0
的值表示

讓我們考慮:C++移植的方式得到一個U8字符串字面

char const str[] = u8"ñ"; 
auto const* u8_code_units = reinterpret_cast<unsigned char*>(str); 
// using u8_code_units elements 

那是完全便攜和C++標準兼容?或者有一些條款說明它是未定義的行爲或取決於任何未指定的值?我知道unsigned charchar應具有相同的對齊要求,並且reinterpret_cast<T*>(v)等於在這種情況下爲static_cast<T*>(static_cast<void*>(v)),所以我認爲使用它完全安全和便攜,但我不確定。

回答

2

這是完全可移植的且符合C++標準嗎?

有點,但不是你想的原因。

請參閱,您必須以某種格式實際上將該文件保存到磁盤。這意味着您的編譯器必須能夠以相同的格式讀取。而編譯器支持的文本格式是實現定義的。然而,如果你的編譯器支持你保存它的格式,並且這種格式可以保存Unicode編碼的字符,那麼你的編譯器會在這裏做正確的事情。

即使reinterpret_cast是好的,因爲編譯器要求char陣列可以通過unsigned char陣列進行訪問,即使該平臺的char簽署。而且該標準明確要求,通過unsigned char讀取UTF-8格式的char陣列時,您將獲得您期望從UTF-8格式化中獲得的位。然而

注:

我知道,無符號的字符與字符應具有相同的對齊要求和的reinterpret_cast(V),在這種情況下等於到static_cast(的static_cast(V)),

這不足以保護你。因爲標準顯式地表示它適用於這種特殊情況,並不是因爲對齊要求等原因。 charunsigned char對允許使用別名的規則有例外;對齊與它無關。

+0

需要對齊需求,以確保從'void *'到'T2'的轉換在'static_cast (t2)'之前返回與't2'相同的存儲位置。這就是我評論它的原因。並感謝指出我的「別名」的事情。我搜索了一下,並且我已經在標準中發現嚴格的別名異常(3.10§10)。 –

+0

相關問題:是讀取底層字節的唯一方法嗎? –

+0

@ Peregring-lk:你可以把它看作char。該標準保證在'unsigned char'範圍內0-255,映射到'char'的值爲1:1。因此,如果將值0x80轉換爲「char」,則保證與0x80的「unsigned char」值相等。當然,如果你想擺弄UTF-8操作,你需要將它們讀作'unsigned char'。 –