2017-08-31 46 views
1

根據該C++ 14標準,C++:實現定義的接受的物理源文件中的字符

§2.2.1.1 [...]接受的一組物理源文件中的字符是 實施-defined。 [...]不包含在 基本源字符集中的任何源文件字符將替換爲指定該字符的通用字符名稱 。 [...]

這是否意味着C++標準不提供實現定義的或有條件支持的非UCS/Unicode字符?例如,物理源文件編碼包括沒有相應UCS碼點的字符。

唯一能想到的是,如果情況如此(編譯器通過非UCS編碼支持非UCS字符),編譯器必須使用私有UCS範圍來映射這些物理字符,但無論如何,解決方案不適合「指定該字符的通用字符名稱」部分,因爲專用範圍內的UCS代碼點根本沒有定義任何特定字符。

回答

1

不是。 。有點。在[lex.phases]報價的重要組成部分,IMO如下:

物理源文件字符映射,[...],基本源 字符集

只有基本的源代碼字符集支持,一切必須以某種方式映射到它([lex.charset]):

a b c d e f g h i j k l m n o p q r s t u v w x y z 
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 
0 1 2 3 4 5 6 7 8 9 
_ { } [ ] # () < > % : ; . ? * + -/^ & | ~ ! = , \ " ’ 

但標準還表示,如果有必要它應該這樣做。它繼續說下面的內容:

接受的源文件字符的物理集合是實現定義的。

所以我想,它允許編譯器爲所欲爲到底,只要它至少支持基本的字符集。

+0

無論如何,必須使用通用字符名稱語法將* impl-defined字符接受*超出*基本字符,才能轉換爲UCS代碼點。但是如果某些字符沒有相應的UCS代碼點呢? –

+0

我會假設編譯器將無法翻譯。你是否試圖在家庭釀造的字符集中編碼? – AndyG

+0

您好xD我只是想了解編碼/ C++標準混亂和他們的概念交互。 –

相關問題