ユニコードまたはマルチバイト文字セットを使用してプロジェクト（ここでは主にc ++を考えます）を作成する場合、StackOverflowコミュニティはどのように考えているのでしょうか。
すべての文字列がワイドフォーマットになることを意味する、最初からUnicodeを直接使用することの利点はありますか？より大きな文字の標準的な使用のために、パフォーマンスの問題/より大きなメモリ要件がありますか？
この方法には利点がありますか？一部のプロセッサアーキテクチャは、ワイド文字をより適切に処理しますか？
追加の言語をサポートする予定がない場合、プロジェクトをUnicodeにする理由はありますか？
マルチバイト文字セットでプロジェクトを作成する理由は何ですか？
上記のすべての要素は、高性能環境（最新のビデオゲームなど）でどのように衝突しますか？
私がコメントしたい2つの問題。
まず、ターゲットにしているプラットフォームについては言及しません。最近のWindowsバージョン（Win2000、WinXP、Vista、Win7）は、文字列を使用したシステムコールのマルチバイトバージョンとUnicodeバージョンの両方をサポートしていますが、Unicodeバージョンの方が高速です（マルチバイトバージョンは、Unicodeに変換し、Unicodeバージョンを呼び出し、返されたものを変換するラッパーです。文字列をマルチバイトに戻します）。したがって、これらのタイプの呼び出しを多数行う場合は、Unicodeの方が高速になります。
追加の言語を明示的にサポートする予定がないという理由だけで、アプリケーションがユーザーによって入力されたテキストを保存および表示する場合は、Unicodeのサポートを検討する必要があります。アプリケーションが非言語的であるという理由だけで、すべてのユーザーが非言語的であるとは限りません。彼らはあなたの英語のGUIを使って完全に満足しているかもしれませんが、名前、コメント、または他のテキストを自分の言語で入力して、それらを適切に表示させたいと思うかもしれません。
ここでVC++プロジェクトの設定について話しているのですね。
影響を受けるのは、Win32API呼び出しのバージョンが実行されることだけです。たとえば、への呼び出しは、マルチバイト設定の場合、およびUnicode設定の場合のMessageBoxへの呼び出しとして終了します。もちろん、それはその関数の文字列パラメータのタイプにも影響します。内部的には、文字列パラメータを現在のシステムロケールからUnicodeに変換した後に呼び出します。MessageBoxAMessageBoxWMessageBoxAMessageBoxW
私のアドバイスは、Unicode設定を使用し、Unicode文字列をWin32API呼び出しに渡すことです。それは、内部で他のエンコーディングで文字列を使用することを妨げるものではありません。
簡単な答え（IMO、そして私は間違っていることを証明してきました）は、より悪いこと（またはあなたの見方によっては最善）を計画し、今すぐユニコードを実行する方がよいということです。
アプリケーションが非常に文字列を集中的に使用しない限り、Unicodeに直接アクセスすることは実際には重要ではありません。ゲームの場合、それはエンジンの他の部分と比較して大きな要因ではないはずです。
最大。
簡単な考慮事項は次のとおりです。菅直人さんが使用した場合、プログラムは機能する必要がありますか？彼のホームディレクトリはASCIIで表現するのが難しいかもしれません。
最初からUnicodeを直接使用することの長所はありますか？
数年後、100万行のコードがあれば、「はい」と答えていればよかったと思うでしょう。
すべての文字列がワイドフォーマットになることを意味しますか？
Microsoftが「Unicode」とUTF-16の混同をやめたいと思います。
すべての文字列をワイドフォーマットで保存する必要はありません。代わりにUTF-8を使用すると、メモリフットプリントが小さくなり（ラテンアルファベット言語の場合）、7ビットASCIIとの下位互換性が得られます。
WindowsでUTF-8を使用することの1つの欠点は、ANSIコードページとしてサポートされていないことです。そのため、WinAPI呼び出しを行うには、文字列をUTF-16に変換する必要があります。これがどの程度の不便を引き起こすかは、Windowsプログラムを作成しているのか、Windows上で実行されるプログラムを作成しているのかによって異なります。
その質問への最初の答えは...あなたが知る必要があるすべてに答えるべきです。