2017-03-11 27 views
0

私は10.1(クラン3.3)C++ Builderでの新しいC++ 11のWin32/64のプロジェクトを計画し、それがコア機能に来るとき、ほとんどのポータブルな方法でそれを実装することを考え、私が使用したいのですstd::stringエンコーディングの場合はUTF-8です(また、SQLiteCppのデフォルトのエンコーディングであるため、使用するSQLite C++ラッパー)。私は<codecvt>年代と<locale>std::wstring_convert<std::codecvt_utf8_utf16<wchar_t>>から.to_bytes().from_bytes()機能を使用することを決めたのWin-APIと対話するためのstd :: wstring_convert <std :: codecvt_utf8 <wchar_t>>を入れる場所は?

だから、今、私が知りたいのですが、コンバータのオブジェクトを配置するベストプラクティスは何ですか。

私は、例えば、それは独自のユニットと名前空間与えるべきです

... 
#include <codecvt> 
#include <locale> 

namespace cnv 
{ 
    extern std::wstring_convert<std::codecvt_utf8_utf16<wchar_t>> wcu8; 
} 
... 

た.cpp:

の.h

... 
namespace cnv 
{ 
    std::wstring_convert<std::codecvt_utf8<wchar_t>> wcu8; 
} 
... 

とは、それがどこでも必要なcnv::wcu8.to_bytes(xyz)を使用することを含ん?

それとも、私がエンコーディングの間で変換する必要があり、各機能の実装内でインスタンスを作成することが良いですか?

+1

唯一の意図がWIn32/64の場合、なぜポータブルにする必要がありますか?その場合、変換を忘れてwstringだけを使用することもできます。 – Brandon

+1

これはWindows *用*のためであり、将来他のシステム向けにコンパイルされる可能性があります。 – FlKo

+1

'std :: wstring_convert'を使った私の経験は、GCCとclangはそれほどうまくサポートされていないということです。特に、Travis CIのデフォルトのコンパイラは、 'codecvt'ヘッダを含むことを憂慮しています。ちょうど私の2セント。 – rwols

答えて

1

それはスレッドセーフではありませんし、あなたに多くを購入していないので、私はグローバル変数にstd::wstring_convertを保管しないでしょう。毎回std::wstring_convertをインスタンス化するとパフォーマンスが低下する可能性がありますが、それは最初の問題ではありません(早すぎる最適化)。

だから、僕は関数にその事をラップしたい:

std::wstring utf8_to_wstr(const std::string& utf8) { 
    std::wstring_convert<std::codecvt_utf8_utf16<wchar_t>> wcu8; 
    return wcu8.from_bytes(utf8); 
} 

std::string wstr_to_utf8(const std::wstring& utf16) { 
    std::wstring_convert<std::codecvt_utf8_utf16<wchar_t>> wcu8; 
    return wcu8.to_bytes(utf16); 
} 

あなたがどこかstd::range_error例外をキャッチする必要があります。何らかの理由で変換が失敗した場合(無効なコードポイントなど)、std::wstring_convertによってスローされる可能性があります。

後で文字列変換に関するパフォーマンスのボトルネックをヒットした場合、あなたはまだ、コード、電子の重要なポイントで直接std::wstring_convertをインスタンス化することができます。 g。多くの文字列を変換する長い実行ループの外側

関連する問題