これは私がいつも答えを知りたいと思っていた質問ですが、実際には尋ねられませんでした。
ある言語、特にインタプリタ言語で記述されたコードは、コンパイルされた言語で記述されたコードによってどのように呼び出されますか。
たとえば、C ++でゲームを作成していて、Schemeで作成するAIの動作の一部を外部委託しているとします。Schemeで書かれたコードは、コンパイルされたC ++コードで使用できるようになるにはどうすればよいですか？C ++ソースコードでどのように使用され、C ++コンパイル済みコードでどのように使用されますか？使い方に違いはありますか？
どこでも機能する質問に対する単一の答えはありません。一般に、答えは、2つの言語が「何か」（セットまたはルールまたは「呼び出しプロトコル」）について合意する必要があるということです。
大まかに言うと、プロトコルは次の3つを指定する必要があります。
詳細はプロトコル自体に大きく依存します。
時々、2つの言語は一緒に働くために共謀します。2つの言語が、外部で定義されたプロトコルをサポートすることに同意する場合があります。最近では、OSまたは「ランタイム環境」（.NETおよびJava）も関係していることがよくあります。能力が一方向にしか進まない場合があります（「A」は「B」を呼び出すことができますが、「B」は「A」を呼び出すことができません）。
これは、OSと通信するときにどの言語でも直面する問題と同じであることに注意してください。LinuxカーネルはSchemeで書かれていません。
Windowsの世界からのいくつかの典型的な答えを見てみましょう：
CとC++：C ++は、「Cプロトコル」のゆがんだ（「マングル」）バリエーションを使用します。C ++はCを呼び出すことができ、CはC ++を呼び出すことができます（ただし、名前が非常に乱雑になる場合があり、名前の翻訳に外部の支援が必要になる場合があります）。これはWindowsだけではありません。これは、両方をサポートするすべてのプラットフォームに一般的に当てはまります。最も人気のあるOSも「Cプロトコル」を使用しています。
VB6とほとんどの言語：VB6の推奨される方法は「COMプロトコル」です。他の言語は、VB6から使用できるようにCOMオブジェクトを記述できる必要があります。VB6はCOMオブジェクトも生成できます（ただし、COMオブジェクトのすべての可能なバリエーションではありません）。
VB6は、「Cプロトコル」の非常に限られたバリエーションを話すこともでき、その後、外部に電話をかけることしかできません。「Cプロトコル」を介して直接話すことができるオブジェクトを作成することはできません。
.NET言語：すべての.NET言語は、同じ低水準言語（IL）にコンパイルされて通信します。ランタイムは通信を管理し、その観点からは、それらはすべて同じ言語のように見えます。
VBScriptと他の言語：VBScriptはCOMプロトコルのサブセットのみを話すことができます。
もう1つの注意：SOAP「Webサービス」は、人気が高まっている他の多くのWebベースのプロトコルと同様に、実際には「呼び出しプロトコル」でもあります。結局のところ、それはすべて、異なる言語で書かれたコードと話すことです（そして、その時点で別のボックスで実行されます！）
モジュールがどのように通信するかについてのプロトコルがあります。これは、それがどのように機能するかについての高レベルで広範な概要です。
C ++からSchemeを呼び出すシナリオの場合、Schemeインタープリターは、Scheme関数/オブジェクトに動的にバインドする関数をエクスポートして呼び出す可能性があります。Schemeモジュールがコンパイルされている場合、C ++モジュールがそれにバインドできるように、おそらくエントリポイントをエクスポートするオプションがあります。私はSchemeにあまり精通していないので、他の誰かが私よりもその特定のバインディングの詳細に答えることができるでしょう。
通常、C ++コードは、スクリプト言語のインタープリターを呼び出します。コンパイルされたコードとスクリプトコードの間の相互作用の程度はインタプリタに依存しますが、2つの間でデータを渡す方法は常にあります。インタプリタによっては、Rubyオブジェクトのメソッドを呼び出すC ++関数など、一方のオブジェクトをもう一方の側から操作できる場合があります。一方の実行を他方から制御する方法さえあるかもしれません。
実行可能ファイル内でインタプリタのライブラリをコンパイルしなくても、2つの環境を統合することもできます。exeファイルとSchemeexeファイルをシステム上の別々のプログラムとして保持します。メインのexeから、Schemeコードをファイルに記述し、system（）またはexec（）を使用してSchemeインタープリターを実行できます。次に、スキームインタープリターの出力を解析します。
上記で提案されたアプローチは、exeを分離し、サードパーティの依存関係について心配する必要はありません。それらは重要になる可能性があります。また、問題は1つのexeファイルまたは別のexeファイルに含まれたままになります。
別のexeを実行してもパフォーマンス要件が満たされない場合は、Schemeインタープリターがサーバーになるプロトコルを考案できます。ソケットまたはファイルへの入力を待機するいくつかのScheme関数を記述し、その入力を評価してから、結果を同じソケットまたは別のファイルに出力する必要があります。これのもう1つの反復は、インタプリタをすでに実行している可能性のある既存のサーバーを調べることです。たとえば、apacheには、コードを多くの言語で記述できるモジュールがあります。
10年ほど経ちましたが、私は先輩の絶頂のためにまさにこれを行いました（まあ、私はCで逆伝播ニューラルネットワークを構築し、それを教えるためにスキームプログラムを使用しました）。私が使用していたSchemeのバージョンには、コンパイラーとインタープリターがあり、.oファイルとしてビルドすることができました。実行していたスキームのバージョンはわかりませんが、RSchemeによってスキームコードがCに変換されるようです。
理論的な観点から、プログラムAがプログラムBのリソース（クラス/関数など）を使用する必要がある場合、それはAからBにいくつかの情報を渡し、いくつかの情報を取り戻すか、いくつかのアクションを実行することです。したがって、Aが情報を渡して結果を取得できるようにするBが提供する方法が必要です。
実際には、通常、このプロセスを処理するのは言語の肩にかかっています。言語B（プログラムBが記述されている）はプロトコルを生成し、事前定義された方法でBのリソースを使用可能にし、言語A（プログラムAはで記述されます） ）公開されたリソースを呼び出し、Bのプロトコルに従って結果を得るのに役立つユーティリティ/フレームワークを提供します。
あなたの質問にもっと具体的に言うと、インタプリタ言語の場合、プロセスはかなり普遍的であり、プロトコルは通常、コマンドラインパラメータ、HTTPリクエスト、およびプレーンテキストを送信する他の方法の行の中にあります。最初の例を見ると、プログラムBは入力としてHTTPリクエストからの呼び出しを受け取り、そこからリクエストを処理します。入力の実際の形式は、プログラムBによって完全に決定されます。
SOAPなどは、一般的に合意された標準で入力を受け取るようにプログラムを規制する方法にすぎません。
あなたが実際にそのようなことをするためのツールを探しているなら、アダムの応答、swigを見てください。