2つのアプリ間のローカル通信
C++でプラットフォームに依存しないプログラムを作成するには、GUI（OSごとに個別に、ネイティブライブラリ/ APIを使用）と実際のプログラムを分離します。明らかに、これら2つは互いに通信する必要があります。
XMLファイルを保存して読み取ることでこれを行うことは、1つのソリューションになります。これは遅い/常に変更をチェックする必要があるので、プログラムの処理部分がlocalhost上の「サーバー」を提供し、GUIがその「サーバー」と通信するソリューションを好むでしょう。このアプローチについてどう思いますか？そして、どのように私はそれを技術的にしますか？
プロセス間通信 の問題に対処します。これはプラットフォームに依存しない必要があるという制約と、同じマシン上にある他の制約（より多くの設計オプションを解放する）を伴います。
このアプローチには本質的に問題はありません。私は覚えています Mathematicaはこのアプローチを使用しています （計算エンジン（「カーネル」）とGUIは2つの別々の部分です-これにより同じマシンで実行したり、計算エンジンをヘッドレスUNIXに置いたりできますそこにボックスし、デスクトップにGUIを表示します）。この構造が機能し、うまく機能する理由はたくさんあります。
一方、2つの部分を厳密に分離することにより、システムに複雑さを追加します。これは良いことかもしれませんし、そうでないかもしれません。そのような構造のもう1つのビットは、2つのパーツ間のアームの長さの距離によって、いくつかの簡単なライセンスオプションが可能になることです（GUIにはGPLライブラリが含まれていますが、バックエンドをGPLにしたくない）。
他のクライアント/サーバーシステムでも同様のことが行われます。 PERFORCE（バージョン管理システム）にはサーバーとクライアント（各プラットフォーム用のカスタムビルド）があります。クライアントとサーバーを非常に別個のプログラムとして保持することで、維持が困難な巨大なアプリケーションではなく、懸念事項の分離を維持できます。
アプリケーションを1つのアプリケーションとして直接リンクすることは、設計上の問題が最も少ない最も単純なアプローチです...しかし、それをしたくないので...
共有リソース
共有ファイル
最も単純なのは、それぞれが書き込みと読み取りを行う共有ファイルです。それはreally簡単です（私は初期の頃のゲームを思い出します-ローカルエリアゲームに共有ファイルを使用したSpaceward Ho）。それはちょっと不格好ですが、動作します。
共有fifo
これのバリエーションは 名前付きパイプ で、ファイルのように見えますが、そうではありません。まあ、それはファイルであるという点でisファイルですが、それはあたかもそれのようにアクセスできるプログラムの出力（または入力）ですファイルでした。
共有メモリ
複数のプロセスが書き込める メモリのセグメント を使用することもできます。共有メモリの良い点は、その通信を盗聴することが難しいことです（それが問題である場合）。また、かなり高速になることもあります。これには、リソースの適切な同期が必要です。ファイルとfifoを使用する場合、OSは、つま先を強く踏みすぎないようにするための安全性を備えていることがよくあります（ファイルはロックされているため、書き込みはできません）。共有メモリは、足元で自分を撃つことからの強力な保護がありません。
信号
ほとんどのシステムには何らかの信号があります。これは機能しますが、データを運ぶことはできません。もっと「ちょっと、目を覚まして！」タイプ情報。したがって、ここにリストしていますが、あなたが探しているものではありません。
ソケット
ソケットベースの通信が可能なシステムで作業している可能性があります。ソケットを開き（localhostをリッスン）、そこにデータを置くことができます。とても簡単です。 1対1の通信で問題なく動作しますが、複数のクライアントがあり、実行している可能性がある場合は、期待していないと少々手間がかかる可能性があります。
メッセージ
メッセージキュー
メッセージキューの膨大なリストの1つを起動（または埋め込む）できます。よく聞く名前はActiveMQ、ZeroMq、RabbitMQです。それらはすべて調べる価値があります。他のオプションを利用できる場合は、このエリアに多数の商用エントリーがあります。これらには、クライアント言語としてC++以外otherを実行したい場合（たとえば、フロントエンドがより適切に処理されることがわかります） .Net on a windows box）、これはまだ簡単に使用できます。
メッセージの受け渡し（リモートメソッドの呼び出し/リモートプロシージャコール）
言語フレームワーク内に留まると、他のいくつかのオプションが提供されます。たとえば、Javaには、Javaの [〜＃〜] rmi [〜＃〜] があり、あるJVMのメソッドを別のJVMから呼び出すことができます。
C++にはRPCまたはRMIが組み込まれていませんが、これを提供するライブラリは数多くあります。 XML-RPC のようなオプション。私は thrift を何かとして言及し、そのクロスランゲージでもあります。
すでに与えられた包括的な答えに加えて：
プラットフォームに依存しないアプローチを探す場合、 Apache Thrift などのフレームワークは、プラットフォームに依存しない通信と言語に依存しない通信の目的で特に設計されているため、一見の価値があります。
特定のアプリケーションで本当に必要な場合は、そのようなフレームワークをメッセージキューまたはサービスバスと組み合わせることもできます。質問で概説された範囲を考えると、後者は私には少しやり過ぎに見えますが、すでに何かをより大きなものにスケーリングすることを計画している場合は、それで十分かもしれません。