私は、メイン プロジェクトからプラグインに分離したい複数の同様のコード パスを持つプロジェクトに取り組んでいます。プロジェクトはクロスプラットフォームの互換性を維持する必要があり、私が調べた動的ライブラリ読み込み API はすべてプラットフォーム固有のものです。
コードを余分に変更することなく、複数のオペレーティング システムでコンパイルおよび実行できる動的ライブラリ ロード システムを作成する最も簡単な方法は何ですか? 理想的には、1 つのプラグインを作成し、プロジェクトがサポートするすべてのオペレーティング システムで動作するようにしたいと考えています。
ありがとう。
ローディングシステムには、プラットフォームに依存するコードを使用する必要があります。WindowsでDLLをロードすることは、Unixで共有オブジェクトをロードすることとは異なります。ただし、2人の#ifdef場合、ローダーにほぼ同じコードベースを含めることができます。
そうは言っても、プラグインプラットフォームを独立させることができると思います。もちろん、プラットフォームごとにコンパイルする必要がありますが、コードは99％同じになります。
WindowsおよびUnix/Linuxをロードするダイナミックライブラリは、3つの関数で動作します。ライブラリをロード/アンロードするための関数のペアと、ライブラリ内の関数のアドレスを取得するための別の関数。これらの3つの関数のラッパーを簡単に記述して、クロスオペレーティングシステムのサポートを提供できます。
理想的には、1 つのプラグインを作成し、プロジェクトがサポートするすべてのオペレーティング システムで動作するようにしたいと考えています。
私の頭の上からいくつかのこと：
動的ライブラリ内の静的オブジェクトは避けてください。オブジェクトを割り当てるための適切な初期化メソッド/関数をプロビジョニングします。ライブラリが OS によってロードされている間に発生する問題 (これは、静的オブジェクトの c'tors が呼び出されるときです) はデバッグが非常に難しく、次はマルチスレッドの問題です。
インターフェイス ヘッダーにはコードが含まれていない場合があります。インライン メソッドも、プリプロセッサの定義もありません。これは、アプリケーションが特定のバージョンのライブラリのコードで汚染され、後でライブラリを置き換えることができなくなるのを防ぐためです。
インターフェイス ヘッダーには、実装クラス自体を含めることはできません。抽象クラスとファクトリ関数のみを含めることができます。前のポイントと同様に、特定のバージョンのクラスに依存するアプリケーションを避けるためです。ファクトリは、ユーザー アプリケーションが具体的な実装クラスをインスタンス化する方法として必要です。
新しいバージョンのインターフェースを導入するときは、下位互換性を維持するために、既存の抽象クラスを変更しないでください。継承された新しい抽象クラスを作成し、そこに新しいメソッドを追加します。factory を変更して、新しいバージョンを返します。(MS の IInterface、IInterface2、IInterface3 などを思い出してください。) 実装では、抽象クラスの新しいバージョンを使用します。ポリモーフィズムにより、実装は古いインターフェース バージョンと下位互換性を持つようになります。(それは明らかに、定期的なインターフェースのメンテナンスとクリーンアップを必要とします - 古いクラフトを取り除くために。)
boost.extension ライブラリを見てください。これは実際にはブーストの一部ではありませんが、サンドボックスで見つけることができます。これも一種の凍結ですが、全体的にライブラリは安定していて使いやすいです。