プラグイン対応アプリケーションについて
reshia
Last update: 2006-06-30
アプリケーション開発をしているとよく後から機能を追加したいと思うことがあります。このとき普通はソースファイルに手を加えて機能を拡張します。しかし、ソースファイルに手を加えようとするとアプリケーション自体の仕様を変更することになったり、誤った修正を行ってしまうかもしれません。また、ある機能を差し替えを行う場合にも同様の問題が起こり得ます。たとえば、アプリケーション開発の最初から機能の修正や追加、変更が行われることがわかっている（予測できる）場合、「プラグイン」というものを使って、この種の問題を解決できます。
本ドキュメントでは、機能拡張や機能変更などを容易に行えるアプリケーション開発について説明します。またプラグインに関する様々な問題や注意点もまとめておきます。
プラグインとは、アプリケーションの機能を拡張するプログラムのことです。アプリケーション本体とは独立していますので、プラグインの機能を修正したい場合にもアプリケーション本体に手を加えることなく修正が可能です（図１）。「アドオン」や「エクステンション」などとも呼ばれます。
|----------------------| |-----------| | |++|プラグイン1| | | |-----------| | | | | |-----------| | アプリケーション本体 |++|プラグイン2| | | |-----------| | | | | |-----------| | |++|プラグイン3| |----------------------| |-----------| （ 図１：プラグインの概念図 ）
アプリケーションとプラグインは、別々のプログラムですので、いちいちアプリケーション全体をビルドし直す必要はありません。つまり、アプリケーション自体は、１度作ってしまえば使い回しができます。
プラグイン化することで、モジュール独立性が高まります。一般的にモジュール独立性が高まると、アプリケーション全体（拡張機能も含む）の開発にかかる工数が減る傾向にあることが知られています。
モジュール独立性が高いため、機能の追加、修正、削除が簡単に行えます。さらにいえばアプリケーション開発者とプラグイン開発者が同じ人物である必要性がないため、プラグインを含めたアプリケーション全体としての開発を並行的に行えるようになります。
プラグインは実行時にも追加と削除が可能です。このためアプリケーション使用者は、自分の目的に合ったプラグインを使うことが可能になります。
たとえば、CPU毎に最適化したプラグインを作っておけば、アプリケーションを実行した環境によってプラグインを切り替えるというようなことも可能です。
後に説明しますが、プラグインのインタフェースはどのプラグインでも同じになります。そのため、保守に際してどの関数をメンテナンスしていいのかが、比較的わかりやすくなります（ただし、目的の異なるプラグインの場合はインタフェースが異なります。詳しくは後述の５章５節を参照してください）。
プラグインを使うことで次の３つのデメリットが考えられます。この３つのデメリットは、立場の違い（アプリケーション開発者かプラグイン開発者）によって解釈の仕方が異なります。
プラグイン開発者の（ｃ）に関していえば、アプリケーション開発者が不要だと思っている機能をプラグイン開発者が開発する必要はないため「特になし」となっています。あるいは、（ｂ）に分類されるかもしれません。
これらのデメリットは、乱暴にまとめてしまえば「プラグインに対する仕様の決定が難しい」だけだといえます。
プラグイン対応アプリケーションの実現方法には、大きく２つの方法があります。
目的とする機能を実現するのに必要な手続きをテキストに記述し、アプリケーションが実行時にそのテキストを読み込み、逐次実行していくタイプのプラグインです。スクリプトタイプのプラグインを実現するには、まずスクリプト言語の仕様を定義します。プラグイン開発者は、このスクリプト言語でプラグインを開発することになります。アプリケーションは、プラグイン開発者が記述したスクリプトを読み込み、その内容を実行します。単に「実行」といっても、字句解析や構文解析、実際のコード生成などが必要になってきます。
本ドキュメントでは、このスクリプトタイプのプラグインは扱いません。このタイプのプラグインに関しては、「スクリプト言語の作り方」のようなページを参考にするといいと思います。
DLL（Dynamic Link Library、動的リンクライブラリ）は、アプリケーションの実行時にリンクされるライブラリです。逆にアプリケーションのビルド時にリンクされるライブラリは「Static Link Library（静的リンクライブラリ）」です（SLLとは呼ばれていません）。
動的リンクライブラリは、アプリケーションとライブラリが独立しているため、後々にライブラリのみを入れ替えることが可能であったり、複数のアプリケーションで共有化することができます（図２）。また、アプリケーション自体のサイズも小さくなります。
静的リンクライブラリは、ビルド時にアプリケーションとリンクされるため、図３のように、アプリケーション実行時にライブラリが存在することが保証されます。
|----------------------| |------------| | | | | | | | | | アプリケーション本体 |---| ライブラリ | | | | | | | | | |----------------------| |------------| （ 図２：動的リンクの概念図 ）
|----------------------|------------| | | | | | | | アプリケーション本体 | ライブラリ | | | | | | | |----------------------|------------| （ 図３：静的リンクの概念図 ）
動的リンクライブラリを使用するには、２つの方法があります。
動的リンクライブラリにある関数を使ったソースコードをコンパイルするとアプリケーション外部の関数を呼び出しているわけですから、オブジェクトコード内に外部関数への参照が生成されます。もちろん、このままでは「未解決の〜〜」などというエラーが発生します。
暗黙的リンクでは、外部参照を解決する手段として、インポートライブラリというものを使います。インポートライブラリには外部参照した関数の確認に必要な情報が提供されています（詳細は省きます）。
一見、インポートライブラリをビルド時に指定するため、あたかもビルド時に必要な外部参照のコードがアプリケーションにリンクされてしまっているように見えます。しかしインポートライブラリ自体には外部参照した関数のコードは含まれていません。あくまで“実行時に”外部参照を解決するコードが自動的に埋め込まれただけです。
（VCでは、プロジェクトの設定でインポートライブラリを指定します。VCでは、C標準ライブラリなどを解決するインポートライブラリが自動的にリンクされます。）
明示的リンクではアプリケーション開発者が外部参照を解決するためのコードを埋め込む必要があります（Windows APIを使います）。このためアプリケーション開発者は、自分の必要なライブラリを必要なときにリンクすることができます。
プラグイン対応アプリケーションでは、この明示的リンクを使う必要があります（実行するまで拡張機能があるかどうかもわからないので）。また明示的リンクでは、インポートライブラリを必要としません。
両者の違いをまとめると、以下のようになります。
| ・ | 外部参照解決方法 | 解決されるタイミング |
|---|---|---|
| 暗黙的リンク | 開発環境が自動に行ってくれる | アプリケーション起動時 |
| 明示的リンク | 開発者が明示的に指示する | 開発者の指示したタイミング |
＊ 通常、静的リンクライブラリの拡張子もインポートライブラリの拡張子も「.lib」ですが、両者の違いは明白です。静的リンクライブラリには、ライブラリ関数のコードが含まれていますが、インポートライブラリには実際のコードは含まれていません。インポートライブラリは、ただDLL関数への外部参照を解決するための情報を持っているだけです。
４章では、サンプルプログラムを作りながら、DLLタイプのプラグインを使ったアプリケーションの実現方法を見ていきます。
本章ではサンプルとして簡単な仕様のプラグイン対応アプリケーションを開発していきます。
| 対象 | C言語（またはC++言語）を使ってWin32プログラミングをしたことがある方。 |
|---|---|
| 開発環境 テスト環境 | OS：Microsoft Windows XP Professional SP2 開発ソフト：Microsoft Visual Studio.NET 2003 開発言語：Visual C++ with Win32 API |
今回重要な役割を果たすのが次のAPIです。
| プロトタイプ宣言 | HMODULE LoadLibrary( LPCTSTR lpFileName // モジュールのファイル名 ); |
|---|---|
| 内容 | 指定された実行可能モジュールを呼び出し側プロセスのアドレス空間内にマップします。 |
| 戻り値 | 関数が成功するとモジュールのハンドルが返ります。失敗するとNULLが返ります。 |
| プロトタイプ宣言 | FARPROC GetProcAddress( HMODULE hModule, // DLL モジュールのハンドル LPCSTR lpProcName // 関数名 ); |
|---|---|
| 内容 | DLLが持つ、指定されたエクスポート済み関数のアドレスを取得します。 |
| 戻り値 | 関数が成功するとDLLのエクスポート済み関数のアドレスが返ります。失敗するとNULLが返ります。 |
ある計算の結果を求めるプログラムを考えます。
この計算には、答えを求める方法が複数あるとします（たとえば「円周率を求める計算」や「擬似乱数を求める計算」などを想像してもらえれば良いかと思います）。
このプログラムでは、後から計算方法を修正したり、あらたな手法で計算結果を求めたりすることが考えられるので、具体的に計算を行う部分をプラグイン化することにします。
この計算には、次の３つの条件があるものとします。
プラグインを使わないアプリケーションの場合、以下のような関数を作ることになる思います。
/* 計算結果を求める */
int Calc(int param1, int param2)
{
int result; /* 計算結果を格納する */
/* 略 */
return result;
}
この関数を複数の計算方法で切り替えたいとするなら、次のような関数を作ることになると思います。
/* 計算結果を手法「AAA」によって求める */
int CalcByAAA(int param1, int param2);
/* 計算結果を手法「BBB」によって求める */
int CalcByBBB(int param1, int param2);
/* 計算結果を手法「CCC」によって求める */
int CalcByCCC(int param1, int param2);
/* ある問題の答えを求める */
int Calc(int param1, int param2);
アプリケーションは、次のようにただ関数「Calc()」を呼ぶだけで、その中身については知らなくても計算結果を得られるようにします。つまり、関数「Calc()」の実装部分をプラグインによって、実行時に切り替えられるようにします。
つまり、プラグイン開発者は必ず関数「Calc()」を定義します。
/* ある問題の答えを求める */
int Calc(int param1, int param2);
以上がプラグインの仕様です。今回は簡単な例にとどめていますが、実際にはプラグイン自体の初期化処理や終了処理を行うための関数が必要であったり、プラグインの名前やバージョンを知るための方法などがあった方が良いかと思います。
ここでは、Win32コンソールアプリケーションを使って、プラグイン対応アプリケーションを作成します。もちろんコンソールアプリケーションである必要はありません。
Visual C++を起動して、「新しいプロジェクト」(Ctrl+Shift+N)を作成します。プロジェクトの種類を[Visual C++プロジェクト]の[Win32]にし、テンプレートから[Win32プロジェクト]を選びます。
適当にプロジェクト名を設定し、OKボタンを押します。「Win32アプリケーションウィザード」にて以下のように設定し、OKボタンを押します。
|============================================================= |------[概要] |------[アプリケーションの設定] | |------[アプリケーションの種類] | | |------ "コンソールアプリケーション" にチェック | | | |------[追加のオプション] | |------ "空のプロジェクト"にチェック | |=============================================================
「新しいファイルを追加」(Ctrl+N)にて、[C++ファイル(cpp)]を追加します。
Win32 APIが必要となりますので、[windows.h]をインクルードします。
#include <windows.h>
プラグインの関数を呼び出す際に、呼び出す関数の関数ポインタがあると便利ですので、前もって定義しておくことをおすすめします。
typedef int (*API_Calc)(int param1, int param2);
int main(void)
{
return 0;
}
HMODULE hmod;
ここでは、LoadLibrary()というWindowsのAPIを呼び出しています。この関数は、DLLやリソースファイルなどのモジュールを実行時に呼び出すための関数です。引数には、呼び出したいモジュールのファイル名（パス）を与えます。
hmod = LoadLibrary("MyPlugin.dll");
プラグインに定義されている関数（以降「プラグイン関数」と呼ぶ）を使うためには、GetProcAddress() APIを使います。
この関数の第１引数に（７）で得たプラグインハンドルを渡し、第２引数にはプラグインに必要な関数名を記述します。引数に無効なハンドルや存在しない関数名を与えた場合、GetProcAddress() は、NULLを返します。
GetProcAddress()を以下のように関数の型にキャストし、関数ポインタ変数に代入することで、関数が使えるようになります（API_Calcは（４）でtypedefしたものです）。
API_Calc Calc;
Calc = (API_Calc)GetProcAddress(hmod, "Calc");
ロードした関数は、普通の関数と同じように使います。
（事前に「Calc != NULL」であることをチェックしてください）
cout << "Result: " << Calc(56, 7) << endl;
ロードしているプラグインを使用し終わったら、プラグインを解放します。プラグインを解放すると、ロードしていた関数も使えなくなります。
FreeLibrary(hmod);
以上で、プラグイン対応アプリケーションは完成です。
複数のプラグインを読み込み、それらを切り替える方法については、５章２節で説明します。
次はプラグイン側のプログラムを開発します。
プラグイン側のプログラムを作ります。
Visual C++を起動して、「新しいプロジェクト」(Ctrl+Shift+N)を作成します。プロジェクトの種類を[Visual C++プロジェクト]の[Win32]にし、テンプレートから[Win32プロジェクト]を選びます。
適当にプロジェクト名を設定し、OKボタンを押します。「Win32アプリケーションウィザード」にて以下のように設定し、OKボタンを押します。
|============================================================= |------[概要] |------[アプリケーションの設定] | |------[アプリケーションの種類] | | |------ "DLL" にチェック | | | |------[追加のオプション] | |------ "空のプロジェクト"にチェック | |=============================================================
モジュール定義ファイルは、DLLの外部に公開する関数を設定するファイルです。モジュール定義ファイルを追加するには、[新しい項目の追加（Ctrl+Shift+A）]で[DEFファイル(def)]を選び、ファイル名を指定し [OK]ボタンを押します。
モジュール定義ファイルの中身は、以下のように記述します。
; 行頭にセミコロンを書くと、その行がコメントになります。
; この定義ファイルで各種情報を設定するDLLの名前
; 複数のDLLを出力する場合に、DLL名によって区別する。
LIBRARY MyPlugin
; エクスポートする関数の設定
EXPORTS
; [エクスポートする関数名] (@序数)
; 序数は、外部から関数名でなく序数でアクセスするための数字。
; 序数は省略可能
Calc @1
このようにＤＬＬでは、ＤＬＬの外部に公開する関数をモジュール定義ファイルに記述しますが、すべての関数を外部に公開する必要はありません。
以降では、外部に公開した関数のことを「エクスポート関数」と呼ぶことにします。
モジュール定義ファイルについてのもう少し詳しい情報は、５章１節で説明します。
「新しいファイルを追加」(Ctrl+N)にて、[C++ファイル(cpp)]を追加します。
特に必要なヘッダはありませんが、もしアプリケーション開発者がプラグイン開発者向けに公開しているヘッダ（プラグイン関数のプロトタイプ宣言などがされている）があるのであれば、それをインクルードした方が良いでしょう。
プラグインに必要な関数を定義します。
今回のサンプルでは、Calc()関数のみが必要です。
もちろん、Calc()以外の関数も定義可能です。
int Calc(int param1, int param2)
{
return param1 + param2;
}
これでプラグインは完成です。ビルドでエラーが出る場合は、以下の点を見直してください。
実行前にプラグインのDLLファイルを以下のいずれかのフォルダに置きます。以下のフォルダに目的のDLLが内場合、LoadLibrary()は失敗します。
（１）は、よくわかっていませんが、恐らくLoadLibrary()の引数にフルパスを指定したときのディレクトリのことだと思います。
４章で紹介しきれなかった部分を掻い摘んで紹介します。
モジュール定義ファイルを使わなくても、DLLを作ることができます。
しかし、モジュール定義ファイルを使うことで、次の利点が得られます。
モジュール定義ファイルを使わない場合、関数名の前後にユニークな識別子が付加されて関数がエクスポートされます（「?Function@@YAHHH@Z」など）。そのため、アプリケーションからDLLにアクセスする際に余計な文字列を埋め込む必要が出て、保守が難しくなります（プラグインの仕様が変わるたびにプリフィックス／サフィックスが変わる）。
プラグインのソースファイル内で定義した関数名とは違う名前で外部にエクスポートできます。たとえば、プラグイン開発時には「Func」という名前で定義した関数を、エクスポートする際には「Function」にしたいという場合は、以下のようにモジュール定義ファイルに記述することで左辺値に指定した名前でエクスポートできるようになります。
LIBRARY MyPlugin
EXPORTS
; 左辺値：実際にエクスポートされる関数名
; 右辺値：コード上の関数名
Function = Func
複数のプラグインを読み込む場合、以下のようにします。
プラグインを区別するために、ハンドルは複数用意します。
HMODULE plugin[MAX_PLUGIN];
定義した関数ポインタの変数も複数用意します。
API_Calc Calc [MAX_PLUGIN];
また次のように１つのプラグインに必要な情報を構造体としてまとめておきます。こうすることでプラグインの数が増えた際などの拡張性や保守性が高まります。
struct MyPlugin
{
HMODULE hmod;
API_Calc Calc;
API_Init Init;
API_GetName GetName;
API_GetVerNum GetVerNum;
};
複数のプラグインや関数のロード／解放は、LoadLibrary()などを使って１つずつロード／解放していきます。
MyPlugin plugin[MAX_PLUGIN];
for (int i = 0; i < MAX_PLUGIN; i++) {
plugin[i].hmod = LoadLibrary(filepath[i]);
plugin[i].Calc = (API_Calc)GetProcAddress(hmod, "Calc");
plugin[i].Init = (API_Init)GetProcAddress(hmod, "Init");
/* 略 */
}
/* 略 */
for (int i = 0; i < MAX_PLUGIN; i++) {
FreeLibrary(plugin[i].hmod);
}
普通、プラグインを読み込む際には、（そもそも後から追加されるのですから）プラグインの入っているDLLのファイル名をビルド時に知ることはできません。
そこで、プラグインのファイル名を知るために、Win32 APIのFindFirstFile()とFindNextFile()を使用してファイル名を１つずつ取得します。詳細は割愛しますが、以下のコードで「./plugin」以下にある拡張子「.dll」のファイルの一覧が表示されます。
WIN32_FIND_DATA w32findData;
HANDLE hFind;
/* pluginフォルダ直下の「.dll」ファイルを検索する */
hFind = FindFirstFile(".\\plugin\\*.dll", &w32findData);
if (hFind == INVALID_HANDLE_VALUE) {
std::cout << "There is no plugin." << std::endl;
}
do {
/* 検索パターンにマッチするファイル名を出力する */
std::cout << w32findData.cFileName << std::endl;
/* 次のファイルを検索する。存在しなければ、戻り値はfalseとなる */
} while( FindNextFile(hFind, &w32findData) );
/* 検索を終了する */
FindClose(hFind);
複数プラグインを読み込む場合は、一度だけ上記の操作を行いプラグインファイル名のリストを持っておくといいと思います。
読み込むDLLの拡張子が[.dll]である必要はありません。[.plugin]でも何でもかまいません。
プラグインは、目的にあわせて仕様を規定するべきです。たとえば、４章のサンプルでは計算を行うプラグインを作成しました。これからさらに計算結果を表示するプラグインを作成するとします。
このときに表示する機能と計算する機能は、本質的に関係のないものです。それならば、表示するプラグインには表示に関係する仕様を定義し、計算するプラグインには計算に関するプラグインを定義するべきです。
仕様を機能ごとに分離することで、プラグイン開発者は無駄な関数を定義する必要がなくなり、プラグイン自体のデータ容量も抑えることが可能になります。
プラグインの種類を実行時に識別するには、以下の３つの方法があります。
プラグインからアプリケーションの関数を呼ぶことが可能です。
方針は、プラグイン側に関数ポインタを渡せるような関数を用意するだけです。アプリケーションは、その関数によって、プラグインから呼ばれる関数をセットします。
■サンプルコード：アプリケーション側
void AppFunc(int val)
{
}
/* 略 */
PlugFunc(AppFunc);
■サンプルコード：プラグイン側
typedef void (*AppFunc)(int val);
void PlugFunc(AppFunc appfunc)
{
appfunc(2);
}
プラグインがプロセスにロードされた時点で何らかの処理を行いたい場合、「DllMain」という関数を定義します。また、プロセスから破棄されようとしている場合にも呼び出されます。
|--------------------------------------------------------| | BOOL WINAPI DllMain( | | HINSTANCE hinstDLL // DLLモジュールのハンドル | | DWORD fdwReason, // 関数を呼び出す理由 | | LPVOID lpvReserved // 予約済み | | ); | |--------------------------------------------------------|
詳細は、プラットフォームSDK「DllMain」を参照してください。
正確にいうと、ここで紹介する方法は「クラスのプラグイン化」ではなく、「プラグインにクラスを含める方法」です。ただ、実質的にはクラスをプラグイン化しています。
クラスをプラグインに含めるだけなら、何も考えずに行うことが可能です。しかしクラスをエクスポートする場合には面倒になります。そもそもモジュール定義ファイルにクラス名を記述できませんし、記述できたとしても関数ポインタに相当する機能がＣ＋＋にはありません。
（関数の型情報を持つ型が関数ポインタであるなら、クラスの型情報を持つ型としてクラスポインタがあってもいいのですが、普通「クラスポインタ」といえば、あるクラスのインスタンスへのポインタを指します。宣言するようなものは、エクスポートできないことになります。）
しかしクラスをエクスポートするのではなく、クラスのインスタンスを作成する関数をエクスポートするのであれば、クラスを間接的にエクスポートすることが可能です。
多少、面倒ですが、クラスをエクスポートするには、次の利点があります。
クラス内の関数メンバは、クラススコープに入っているため、オーバーロードも可能です。
グローバルスコープに関数を並べていくだけでは、プラグインの拡張や保守が段々と難しくなってきます。たとえば複数種のプラグインがある場合に、種類毎にクラスとして扱うことができます。
種類の区別を、クラスのインスタンスを作成する関数がエクスポートされているかどうかで判断することが可能です。
具体的なクラスのプラグイン化については６章で説明します。
本章では、クラスをプラグイン化するための方法を説明します。
クラスを含んだプラグインのことを以降では「プラグインクラス」と呼ぶことにします。
プラグインクラスの実現には、デザインパターン「FactoryMethod」を用います。つまりアプリケーションでは、プラグインクラスのインスタンスを作らずに、プラグイン内で作られたインスタンスを利用します。
簡単な例を見てみます（実際にはビルドエラーになります）。
■サンプルコード：アプリケーションの公開ヘッダ
class MyClass
{
public:
MyClass(void);
const char* GetName(void);
};
MyClass* MakeInstance(void);
■サンプルコード：プラグイン内
/* 公開ヘッダをincludeしておくこと */
MyClass::MyClass(void) {}
const char* MyClass::GetName(void) {return "MyPlugin";}
MyClass* MakeInstance(void) {
return new MyClass();
}
■サンプルコード：アプリケーション
/* プラグインクのMakeInstance()をあらかじめロードしておきます */
MyClass* instance = MakeInstance();
cout << instance->GetName() << endl;
delete instance;
公開ヘッダでは、MyClassの定義のみを行い、実装を行いません。
プラグインでは、MakeInstance()関数のみをエクスポートするようにします。
アプリケーションでは、プラグインからロードしたMakeInstance()関数のみを利用し、直接MyClassのインスタンスを作らないようにします。
このように、実際にはクラスをプラグイン外部に公開しなくても、あるエクスポートされた関数を使って特定のクラスを生成・解放することでプラグインクラスを実現できます。
本節では、簡単なサンプルプログラムを用いて、プラグインクラスの実現方法を説明します。
プラグインクラス内の関数メンバはすべて仮想関数である必要があります。
またコンストラクタ・デストラクタはprotectedに指定します。これはアプリケーションが直接プラグインクラスのインスタンスを作れなくするためです。こうする理由は、６章３節にて説明します。
インスタンスを作るには、プラグイン側で定義するインスタンス生成／解放を行う専用の関数を使います（前節で説明しました）。この関数は、プラグインクラスのフレンド関数に指定することで、プラグインクラスのprotectedなコンストラクタ／デストラクタを呼び出すことを可能にします。
class MyPluginClass;
MyPluginClass* MakeInstance(void);
void ReleaseInstance(MyPluginClass* instance);
class MyPluginClass
{
protected:
explicit MyPluginClass(void);
virtual ~MyPluginClass(void);
public:
virtual float GetVersion(void);
friend MyPluginClass* MakeInstance(void);
friend void ReleaseInstance(MyPluginClass* instance);
};
プラグインクラスの実装と、インスタンスの生成と解放を行う関数の実装を行います。インスタンスの生成と解放を行う関数の定義は公開ヘッダで行っても構いません。
/* MyPluginClassのインスタンスを作る */
MyPluginClass* MakeInstance(void)
{
return new MyPluginClass();
}
/* MyPluginClassのインスタンスを解放する */
void ReleaseInstance(MyPluginClass* instance)
{
delete instance;
}
MyPluginClass::MyPluginClass(void)
{
}
MyPluginClass::~MyPluginClass(void)
{
}
float MyPluginClass::GetVersion(void)
{
return 1.03f;
}
公開する関数を規定します。
ここでは、MakeInstance()とReleaseInstance()のみを公開します。
LIBRARY MyPlugin1
EXPORTS
MakeInstance @1
ReleaseInstance @2
プラグインのロードや、エクスポート関数をロードする方法は、４章４節と同じ方法で行います。特に注意すべき点はありません。
/* 公開ヘッダをインクルードしておきます */
typedef MyPluginClass* (*API_MakeInstance)(void);
typedef void (*API_ReleaseInstance)(MyPluginClass* instance);
HMODULE hmod;
/* プラグイン内の関数へのポインタ */
API_MakeInstance MakeInstance;
/* プラグイン内の関数へのポインタ */
API_ReleaseInstance ReleaseInstance;
/* プラグインと関数のロード */
hmod = LoadLibrary("Plugin.dll");
MakeInstance = (API_MakeInstance)GetProcAddress(hmod, "MakeInstance");
ReleaseInstance = (API_ReleaseInstance)GetProcAddress(hmod, "ReleaseInstance");
プラグインで定義されているクラスをロードします。ロードといっても実際には、プラグインで定義されているMakeInstance()関数を使って、目的のクラスのインスタンスを取得するだけです。
クラスのインスタンスは、特に注意することなく普通のクラスとして扱えます。また、MakeInstance()で得たインスタンスは、必ず解放しなければなりませんが、deleteを使ってはいけません（MakeInstance()でnewして取得したものだとは限らないからです。詳しくは６章３節を参考にしてください）。
MyPluginClass* mpc; /* プラグイン内のクラスへのポインタ */
mpc = MakeInstance();
cout << "Version: " << mpc->GetVersion() << endl;
ReleaseInstance(mpc);
これも４章４節と同じ方法で行います。特に注意すべき点はありません。
FreeLibrary(hmod);
プラグインクラスの実現に関して、注意すべき点を書きます
プラグインを開発する際に、公開ヘッダに書かれてあるクラスのメンバはすべて定義すべきです。定義しない場合は、ビルドエラーとなります（だからといって公開ヘッダを編集してはいけません）。
また、公開ヘッダを編集して独自にクラスのメンバを増やすことも可能ですが、公開ヘッダを編集せずに、次項「クラスを継承する」で対応すべきです。
公開ヘッダに定義されるクラスを継承して、メンバを拡張することが可能です。
アプリケーション開発者は、公開ヘッダに定義するクラスが継承される可能性があることを考慮に入れなければなりません（デストラクタを仮想関数にする理由もそこにあります）。
クラスが継承される可能性を考えるのであれば、クラスを純粋仮想関数で構成するのがいいかもしれません。
アプリケーション側でクラスのサイズを「sizeof(MyPluginClass)」のように取得することは危険です。これは公開ヘッダに書かれたクラスのサイズと、プラグインで拡張定義されたクラスのサイズが異なるかもしれないからです。
たとえば、ありがちなのがmalloc()やmemcpy()を使ってクラスのインスタンスを初期化・コピーしようとした場合です。そもそもmalloc()を使うとコンストラクタが呼ばれませんし、memcpy()でクラスをコピーできるとも限りません（２つのクラスのメンバが同じデータのアドレスを指していたら、予期しない動作をしてしまいます）。
前項で、もう１つ忘れてはいけないのが、new／delete演算子によるインスタンスの生成／解放のことです。new演算子は、MakeInstance()によって隠蔽されているので問題ありませんが、delete演算子は危険です（６章１節のサンプルは危険です）。
通常delete演算子は解放したいクラスのデストラクタを呼んで、さらに解放したいクラスのインスタンスをfreeします。このときクラスのインスタンスのサイズ分だけfreeするのですが「インスタンスのサイズ」というのは、アプリケーションとプラグインで異なる恐れがあるのです。
そのため、new演算子がMakeInstance()に隠蔽されたように、delete演算子をプラグイン側で隠蔽してやります。たとえばdeleteはReleaseInstance()という関数で行うようにすれば、クラスのインスタンスが確保されるのも、解放されるのもプラグイン側で行われるようになり、結果として、インスタンスのサイズが食い違わなくなります。
今回作成したサンプルプログラムのアーカイブをダウンロード可能です。すべて7-zip圧縮です。
| 章番号 | サンプル名 | 内容 |
|---|---|---|
| ４章 | C4_SimplePluginAppli.7z | 単純なサンプル |
| ５章１節 | C5_FreeFunctionNameByDefFile.7z | DEFファイルで関数名変更 |
| ５章２節 | C5_SwitchPlugin.7z | 複数プラグイン |
| ５章３節 | C5_ListUpPlugin.7z | ファイルリストを作る |
| ５章６節 | C5_TheFunctionCalledFromPlugin.7z | プラグインから呼ぶ関数 |
| ６章 | C6_PluginClass.7z | プラグインクラス |
| ６章３節 | C6_PluginInterface.7z | プラグインインタフェース |
|============================================================= |------[概要] |------[アプリケーションの設定] | |------[アプリケーションの種類] | | |------ "DLL" にチェック | | | |------[追加のオプション] | |------ "シンボルのエクスポート"にチェック | |=============================================================
Comments are welcome! We can be reached at whoinside_reshia@hotmail.co.jp
2005/06/30 12:50:30 UTC