私は現在、Unicodeに対応することを目的としたクロスプラットフォームのC++ライブラリを開発しています。私は現在、typedefとマクロを介してstd::stringまたはstd::wstringのいずれかをコンパイル時にサポートしています。このアプローチの欠点は、のようなマクロを使用L("string")し、文字タイプに基づいたテンプレートを多用する必要があることです。
std :: wstringのみをサポートするための賛否両論は何ですか？
std :: wstringを使用すると、UTF-8エンコーディングが推奨されるGNU / Linuxユーザーベースのみが妨げられますか？
多くの人は、UCS-2 (std::wstring) ではなく、UTF-8 (std::string) で Unicode を使用したいと考えています。UTF-8 は多くの Linux ディストリビューションやデータベースの標準エンコーディングであるため、サポートされていないと非常に不利になります。Linux では、引数として文字列を使用してライブラリ内の関数を呼び出すたびに、ユーザーは (ネイティブの) UTF-8 文字列を std::wstring に変換する必要があります。
gcc/linux では、std::wstring の各文字は 4 バイトになりますが、Windows では 2 バイトになります。これにより、ファイルの読み取りまたは書き込み (および異なるプラットフォームから/へのコピー) の際に奇妙な結果が生じる可能性があります。クロスプラットフォーム プロジェクトには、むしろ UTF-8/std::string をお勧めします。
為に：
に対して：
std::wstring のみをサポートするための賛否両論は何ですか?
ワイド文字の使用を支持する議論は、ナロー文字ができるすべてのこと、およびそれ以上のことができるということです。
私が知っているそれに対する反論は次のとおりです。
柔軟であることについて: 私は狭い文字と広い文字の両方を処理できるライブラリ (いくつかの kLoC) を維持しています。UNICODEそのほとんどは、テンプレート パラメーターである文字型によるものでした。マクロを覚えていません (つまり、以外)。すべてが柔軟だったわけではありませんが、最終的にはcharまたはwchar_t文字列を必要とするコードがいくつかありました。(ワイド文字を使用して内部キー文字列をワイドにしても意味がありません。)
ユーザーは、ナロー文字のサポートのみを希望するか (この場合"string"は問題ありません)、ワイド文字のサポートのみを希望するか ( を使用する必要がありますL"string")、または両方をサポートするかを決定できます。も（のようなものが必要でしたT("string")）。
std::stringorの使用std::wstringは無関係だと思います。
とにかく、適切な Unicode サポートを提供するものはありません。
国際化が必要な場合は、適切な Unicode サポートが必要であり、ICU などのライブラリについて調査を開始する必要があります。
その後、どのエンコーディングを使用するかが問題になります。これは、使用しているプラットフォームによって異なります。OS 依存の機能を抽象化レイヤーの背後にラップし、適用可能な場合は実装レイヤーで変換します。
使用する Unicode ライブラリによって内部的に使用されるエンコーディングについて心配する必要はありません。
不利益：
wstringは本当にUCS-2であり、UTF-16ではないためです。いつかあなたをすねに蹴ります。そして、それは激しくキックします。