2011-05-16 84 views
11

C++ 03定義了兩種字符類型:charwchar_t。 (讓我們忽略了signed charunsigned char瘋狂)。爲什麼std :: u16cout缺失?

然後將這兩個字符應用於std::basic_string,std::basic_ostream等,如std::string/std::wstringstd::ostream/std::wostream

從流的標準庫還定義全局std::coutstd::wcout

新的C++ 0x標準定義了另外兩種字符類型char16_tchar32_t。但是,唯一新的類型定義是std::u16stringstd::u32string

爲什麼標準不提供std::u16ostream?或者如何處理std::u32cout

+5

你爲什麼認爲它需要它們?流只是一個字節序列。它是否使得以不同格式編寫和讀取流的可能性更小?沒有。一次可以用std :: ostream編寫一個流,然後用std :: u16stream讀取流,這些流就可以工作(所以沒有額外的保護措施來做錯誤的事情)。因此,將流讀入正確類型的對象的響應性仍然落在程序員身上,因爲沒有真正的方法來確定輸入流的類型(它只是一個字節序列)。 – 2011-05-16 16:33:45

+0

無可否認,'std :: u32cout'不可能經常使用。我只能想象國際化應用程序的控制檯輸出。然而,一個'std :: u32ofstream'會立即有用。 – 2011-05-16 16:37:27

+0

@deft_code:我看不出有什麼用處。你需要更詳細地解釋爲什麼你認爲這很有用。您將存儲格式硬編碼到流中,但您沒有方法檢測流是否實際上是使用該格式創建的。 – 2011-05-16 16:55:12

回答

18

會議決定,實施統一輸入輸出流太多的工作是值得的: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2238.html

從紙:

離開了兩種新的流特的理由是,流的非字符類型並沒有引起廣泛的使用,所以目前還不清楚是否真的需要將這種非常複雜的機器的規格化數量加倍。

根據我的理解,標準委員會意識到序列化爲寬字符(2或4字節格式)並不常見,並且您需要UTF-16或UTF-32的位置,您可以始終自己實現使用相同的舊的基於字符的字節流,但是使用codecvt方面將您的輸入轉換爲UTF-16/UTF-32,它可以將它視爲另一種多字節格式。

2

我不知道官方原因。

但我不認爲需要一個。
通過使用具有特定類型的流,您正在使用硬編碼。我希望流是通用的(處理字節),然後您可以自定義輸出爲特定格式。像他們目前的工作。

所以在內部我想使用UTF16字符串。但在輸出上,我想將它們串行化爲UTF8進行存儲。爲此,我只是簡單地創建一個普通的流,將它與一個知道如何從UTF16轉換爲UTF8的語言環境相混淆,然後所有的流都需要處理字節。

讓流很明白磁盤上的格式。有一個可以在不同格式之間轉換的語言環境(在設備上到內部,反之亦然)非常方便。

+0

有時您想要序列化爲UTF-16或UTF-32 - 主要是爲了與其他軟件兼容(例如,某些Windows文件格式使用UTF-16)。但我想你仍然可以使用正確的codecvt方面使用它們。 – 2011-05-16 17:03:30

+0

@Boaz Yaniv:絕對我希望能夠以特定格式序列化。但我不認爲這個流應該控制這個。這是當地的工作,將一種表示轉換爲另一種表示。當您將一個字符串序列化爲一個文件時,您需要知道您將其序列化爲什麼格式,並且在讀取該信息時還需要知道該信息。這是通過將流與適當的本地進行轉換來完成的。 – 2011-05-16 17:14:56

+0

討厭挑剔,但它是「本地化」,而不是「本地化」。 – 2011-05-16 17:24:04

相關問題