在基本多語言平面以外的字符文字代碼點分配char16_t

在今天早些時候我在Unicode上看到的一個演講中，當您嘗試分配字符文字太長而無法用char16_t類型表示時會發生一些混淆。主持人說，根據對標準的閱讀，程序應該是不合格的，但gcc無論如何都會接受它。他沒有澄清，Youtube不允許我提問。在基本多語言平面以外的字符文字代碼點分配char16_t

我自己的測試證實下列代碼被g ++ - 4.8和g ++ - 4.9接受。（帶警告。）

int main() { 
    char16_t a = u'\U0001F378'; 
}

http://coliru.stacked-crooked.com/a/6cb2206660407a8d
https://eval.in/188979

在另一方面鐺3.4產生一個錯誤。

哪個編譯器是正確的？我無法找到這個章節和詩句。

另外一個小問題，字符字面部分§2.14.3在W語法或節體中沒有提及\u和\U轉義序列。這是一個疏忽嗎？

來源

2014-09-05 OmnipotentEntity

該程序不合格，應該編譯失敗。

2.14.3/2文字的字符與字母u，如u'y」開始，是文字型char16_t的一個字符。包含單個c-char的char16_t文字的值等於其ISO 10646代碼點值，前提是代碼點可用單個16位代碼單元表示。（也就是說，只要它是一個基本多語種平面代碼點）。如果該值不是16個比特內所能表述，程序是形成不良的 ...

重點礦。

\u和\U不是2.14.3含義內的轉義序列。它們是通用字符名稱，描述於2.3/2。他們不限於字符和字符串，但可能會出現anywhere in the program：

int main() { 
    int \u0410 = 42; 
    return \u0410; 
}

\u0410爲A，又名西里爾大寫字母A.

來源

2014-09-05 22:20:27

我不能相信，我是正確的部分，完全錯過它。：/ 謝謝。而且，通用字符名稱，我想它們是必需的，但是，爲C++製作合適的IDE的人，就會面臨更多挑戰。我假設翻譯是在象trigraphs這樣的令牌化過程中完成的，這使得有趣的混淆代碼機會成爲可能。 – OmnipotentEntity 2014-09-06 03:00:35

** 2.2/1 **中描述了翻譯的階段，包括處理trigraphs和通用字符名稱的細節 – 2014-09-06 04:24:56

在基本多語言平面以外的字符文字代碼點分配char16_t

回答

相關問題