web-dev-qa-db-ja.com

言語に依存しないAPIを作成しますか？

プラグインモジュールに大きく影響されているC++プログラムを書くつもりです。最初は、APiを他の人が拡張する抽象クラスとして利用できるようにすることだけを考えていました。誰かと話をした後、言語にとらわれない方法でそれを利用できるようにすることを考えるべきだと述べました。

どの言語でもAPIを効果的に公開するにはどうすればよいですか？

私が思いつく可能性のある解決策は、C++直接およびCLI言語（C＃、Fなど）用に、当初意図したようなC++ APIを用意し、その後、一種のドキュメントと実行可能な組み合わせを用意することでした。予想される入力がドキュメントに記述されている場合、実行可能ファイルが（コンソール/ターミナルを介して）起動されます。起動コマンドとしてパラメーターを指定します。これは理論的には機能しますが、私にとっても標準的なソリューションのようには聞こえません。 これは他のデスクトップソフトウェアでどのように行われますか？

c++apilanguage-agnosticdesktop-application
6
user3797758

受け入れられた答えは多かれ少なかれ正しいですが、言語の独立が実際にあなたにとって燃えている問題であるならば、どこへ行くにもあなたを提供しません。 C++は他の言語（C＃、Pythonなど）からかなり呼び出すことができます。質問の口調から見ると、「持っているといい」のように聞こえますが、それ以外の場合は少しの間、ふりをしてみましょう。

プラットフォーム/言語に依存しない通信が重要な場合は、 サービス指向アーキテクチャ を使用する必要があります。 C++コードを独自の自己完結型サービスとして提供する必要があります。これは、テクノロジーにとらわれないネットワークプロトコルを介して要求に応答できます。

これはサーバーアプリケーションの世界ではかなり一般的であり、アーキテクチャ、スケーラビリティ、および他の人のコードの厄介なメモリバグ（+スタックオーバーフローなど）からアプリケーションを保護することで多くの利点があります。

ただし、デスクトップアプリの場合は少し変わっています。私はそれを The Rider IDE で見ました。彼らは主に、ReSharper製品をIDE製品から分離しておくことのアーキテクチャ上の利点のためにそれを使用します。

これは、最終的には物事にとらわれない方法ですが、複数の領域で多くの利点と欠点を持つ重大なアーキテクチャの変更も表しています。それを調べて決定してください。

16
Nathan Cooper

文字通り100％普遍的なものはありませんが、かなりさまざまな言語からAPIを簡単に使用できるようにする方法はいくつかあります（とにかく、ほとんどの人が通常気にしている以上のものです）。

最も明白な（そしてユビキタスな）フォームはRPCです-- gRPC または Thrift （または、Windowsを使用している場合は [〜＃〜]） com [〜＃〜] ）。

これらはすべてほぼ同じように機能します。API自体をインターフェイス定義言語（IDL）で定義します。次に、コンパイラーを使用して、このインターフェースのクライアント側またはサーバー側、あるいはその両方のコードを生成します。これは通常、サーバーのスケルトンを提供します。あなたは実際の機能を満たし、それをすべてコンパイルして、あなたは外に出ます。

8
Jerry Coffin

原則として他の回答にも同意しますが、OPは少なくともいくつかの開始点を期待しています。これは、OPが回答をさらに検索するのに役立ちます。

インプロセス

  • 重要な考慮事項

    • ネイティブコードはアーキテクチャ固有です。つまり、32ビットと64ビットを同じWindowsプロセスに混在させることはできません。
    • 純粋な.NET ILは32ビットまたは64ビット環境で実行できますが、ネイティブコードはアーキテクチャごとに個別にコンパイルする必要があります。
    • これらの制限が問題を引き起こす場合は、代わりにアウトプロセスアプローチを使用する必要があります。

  • Win32 DLL

    • C呼び出し可能な関数をエクスポートします。
    • 整数値、浮動小数点値、プリミティブの配列（バイト配列を含む）などを渡すことができます。
    • 「構造体」に注意し、2つの通信ソフトウェアが各構造体の構造体フィールドの配置に同意することを確認してください。
    • .NETユーザーはP/Invokeを使用してDLLを呼び出すことができます。これは.NETラッパーに変換できます。これにより、基盤となる実装のネイティブな側面を完全に隠すことができます。
  • Microsoft COM
    • 成熟した、推奨
  • C++/CLIを使用した.NET相互運用
    • ほとんどのユーザーが.NETを使用している場合に推奨

プロセス外、同じマシン、非通信（実行中の情報交換なし）

  • コマンドラインアプリケーション。
    • 通信は、コマンドライン引数とファイルを介して行われます。
    • WindowsでI/Oリダイレクトを使用することは、非常に単純なものを除いて信頼できないため、お勧めできません。ドキュメントでは、可能性としてデッドロックについて言及しています。

アウトプロセス、同じマシン、通信

  • WindowsアプリケーションまたはWindowsサービスとして実行することの選択
  • コマンドラインアプリケーションと、プロセス間通信の任意の選択。 Windowsドキュメントのプロセス間通信を参照してください。
    • 共有メモリまたはプロセス間メモリマップファイル
    • プロセス間同期プリミティブ（同期またはセマフォのニーズのみ）
    • プロセス間パイプ
    • ファイルシステム上。同期（ハンドオフ）は、他のいずれかの方法で行う必要があります。または、定期的にフォルダーをスキャンして、ファイルの変更を確認します。
  • WCF

アウトプロセス、異なるマシン、通信

  • アーキテクチャ
    • サーバークライアントアーキテクチャ
    • 分散アーキテクチャ
  • IISで実行されるWebサービスを作成する
  • TCP/IPを介して通信するWindowsサービスとして実行
  • WCFを介して通信するWindowsサービスとして実行
5
rwong

「昔ながら」の、しかしかなり成熟した技術を議論に取り入れるために：

CORBAを使用すると、言語に依存しない方法でオブジェクト指向APIを定義できます（独自のIDL =インターフェイス定義言語を定義します）。言語マッピングは、実際にすべての主要言語（および多くのエキゾチックな言語）でも使用できます。

ローカルおよびリモートのプロセス間通信をサポートします（これは一般的な使用例です）が、サーバーの実装をインプロセスで実行することもできます（その後、直接メソッド呼び出しを使用します）。プロセス間通信プロトコルはバイナリベースであり、非常に高速です。

私たちの会社では、パフォーマンスが重要な場合に引き続き使用しており、相互運用性は常に機能しています（Java、C、C++、C＃、CommonLispの組み合わせを使用）。パートナー企業とのインターフェースにはCORBAを使用しており、多くの場合、使用しているプログラミング言語すらわかりません。

そして、おそらくあなたは知らずにそれをすでに使用したことがあります。例えば。 JavaのRMI/IIOPは事実上CORBAです。

4
Ralf Kleberhoff