C# と C++ の間 (またはマネージ言語とアンマネージ言語の間) の通信は面倒であり、使用する非常に正当な理由がない限り、避けるべきです。
通信には、パイプ、WCF、COM、P/Invoke、およびその他のカスタム商用オプションを使用できます。そのためにネットを検索できます。私が取り組んだエンジンでは、複数のプロセスで共有される匿名の MemoryStream を使用しています。
しかし、常に問題として出てくるのは、C++ の構造上の変更については、C# に反映する必要があるということです。メソッドが取るパラメータや構造体の定義を変更した場合と同様です。C# を自動的に "型取り" して、常に C++ で最新の状態に保つための解決策はいくつかありますが、実装には費用がかかり、重くなります。
さて、なぜあなたは気にしないでください!確かに、ハイエンドの商用エンジンは C++ 以外にはありません。非現実的?C++. ソース?C++. クライシス?C++. C++ は、マネージ言語では提供できないパフォーマンスを提供するためです。また、メモリを直接制御し、オブジェクトの作成方法と消去方法をマイクロ制御することもできます。
では、なぜ気にしてはいけないのでしょうか?Assassin's Creed、Half-Life、または Skyrim のサイズまたは範囲のトリプル A ゲームを出荷する計画がない限り、XNA Framework の下の C# は十分なスペースとパフォーマンスを提供します。必要以上に。実際にパフォーマンスの問題がある場合は、マネージ言語が問題ではない可能性が高く、コードにはまだ多くの最適化が残っているはずです。C# でパフォーマンスの問題が発生した場合、C++ でも問題が発生する可能性があります。
XNA は、Windows、Xbox、およびさまざまな Microsoft ポータブル デバイスで出荷することもできます。その上、とにかく DirectX を使用すると、これらのプラットフォームに制限されます。