std :: iostreamクラスには、char16_tおよびchar32_tの特殊化がなく、boost::formatはストリームに依存します。utf16文字列のストリームを何に置き換えますか(できればローカリゼーションサポートを使用)?
3 に答える
ストリームが機能する基本的なエンティティは文字であり、エンコードされた文字ではありません。Unicodeの場合、1つの文字を複数のエンティティに分割して、ストリームの抽象化と本質的に互換性がないようにすることが決定されました。
新しい文字タイプの追加は、Unicode文字を処理する標準的な方法を処理することを目的としていますが、追加された複雑さに対応するためにIOStreamsとロケールの動作をやり直すには複雑すぎると見なされました。これは、一部にはストリームをあまり愛していない人々によるものであり、一部には大規模で重要なタスクであることが原因です。必要なファセットは単純な状況に対処できるように定義できると思いますが、これが迅速な解決策になるかどうか、Unicodeが必要な言語をカバーするかどうかはわかりません。ヨーロッパのテキストで機能するように作られましたが、アジアのテキストで実際に機能するかどうかはわかりません。
これはいい。エンコーディングの議論は終わり、ほぼ解決しました。レガシーAPIと通信する場合を除いて、プログラムのどこにもutf16文字列は必要ありません。これは、フォーマットされた文字列全体を変換する場合で、boost::narrowおよびwidenを使用するのが最適です。もちろん、まれなエッジケースの最適化を行っている場合を除きます。
http://utf8everywhere.orgを参照してください。
現在のストリームは通常テンプレートとして実装されます(ここには標準のコピーはありませんが、テンプレートとして実装する必要があると確信しています)。したがって、それらをワイドストリング対応にすることは、インスタンス化するだけの簡単な問題です。適切な文字タイプのテンプレート。
ほとんどの場合、実装には、幅の広い文字列用に事前定義された特殊化がすでに含まれています。std::wstringstreamのようなものを探してください。
とは言うものの、C ++のさまざまな文字タイプは、そこに入力する文字列のエンコードについて何も想定していないため、これを「慣例に従って」処理する必要があります。たとえば、ワイド文字列はutf16としてエンコードされます。慣例によりますが、ライブラリにはこの規則を強制するものはありません。