2013-10-07 17 views
0

我試圖在std::basic_stringistringstream的幫助下處理UTF-16字符串(放在緩衝區buf中)。此代碼中出現異常std::bad_cast。我的代碼有問題嗎?或者gcc的STL只能處理unsigned int(16位)符號?std :: bad_cast當使用std :: basic_istringstream <unsigned short>

const unsigned short * buf; 
// ... fiilling buf 
std::basic_string<unsigned short> w(buf); 
std::basic_istringstream<unsigned short> iss(w); 

unsigned int result; 
try { iss >> result; } 
catch (std::exception& e) 
{ 
    const char * c = e.what(); 
} 

std::wstringstd::wistringstream相同的代碼工作正常。

回答

1

對不同字符類型的IOStreams的實例化不是charwchar_t是非常平凡的。這些流需要多個std::locale方面存在。沒有他們,他們將無法正常工作。對於嘗試的操作你需要,至少:

  • std::ctype<cT>
  • std::numpunct<cT>
  • std::num_get<cT>

其中cT是流的性格類型。其中的最後一個應該只是需要實例化,但其他需要實現。當然,您還需要確保爲流設置std::locale,方法是將其設置爲全局區域設置或使用stream.imbue()。個人而言,我認爲這總體上是錯誤的方法:字符在進入系統時應轉換爲內部表示,並在離開系統時轉換爲外部表示(這就是std::codecvt<...>方面的目的)。然而,看起來這是一場失敗的戰鬥,人們覺得他們想要在內部混淆編碼。

+0

謝謝,這個解釋。如果我有一個有效的寬字符串,恰好存儲爲'unsigned short'的數組呢?我可以以某種方式使用'std :: wstring'來處理它,而不需要手動將short數組轉換爲'wchar_t'數組?問題很簡單,在我的平臺上'wchar_t'是4個字節。 –

+0

假設你的源數據是UTF-16編碼的,我猜想這種方法是將它轉換爲內部的'wchar_t'編碼。 –

相關問題