私は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)
を使用することを含ん?
それとも、私がエンコーディングの間で変換する必要があり、各機能の実装内でインスタンスを作成することが良いですか?
唯一の意図がWIn32/64の場合、なぜポータブルにする必要がありますか?その場合、変換を忘れてwstringだけを使用することもできます。 – Brandon
これはWindows *用*のためであり、将来他のシステム向けにコンパイルされる可能性があります。 – FlKo
'std :: wstring_convert'を使った私の経験は、GCCとclangはそれほどうまくサポートされていないということです。特に、Travis CIのデフォルトのコンパイラは、 'codecvt'ヘッダを含むことを憂慮しています。ちょうど私の2セント。 – rwols