DLLの依存関係 – プログラミング – Home

通知
すべてクリア

[解決済] DLLの依存関係


亀山
 亀山
(@亀山)
ゲスト
結合: 18年前
投稿: 133
Topic starter  

VC2005 MFC です。

A.exe
├B.dll
│└Z.dll
├C.dll
│└Z.dll
└Z.dll

という依存関係とする場合、
A.exeがZ.dllの関数を通してZ.dll内のグローバル変数に設定した値を
B.dllやC.dllが自分自身でZ.dllの関数を通して
参照してしまってよいものなのでしょうか?

つまり、Z.dll内で定義されているグローバル変数やオブジェクトは
B.dllやC.dllからのアクセスでも必ず同じものになるのでしょうか?
それとも、スタティックライブラリのときのように別々に存在することも
あり得るのでしょうか?


引用未解決
トピックタグ
仲澤@失業者
(@uncle_kei)
Prominent Member
結合: 5年前
投稿: 828
 

DLLのグローバル変数はそれを使用している実行ファイル(*.exe)
のインスタンス毎に用意されます。
(ただし、DLLがコール理由ごとに妙なローカルデータ処理を
していないことが条件)

そうでないとMFCを使用している複数のアプリケーションなんぞ
まともに動くはずがありませんよねぇ(笑)。


返信引用
ZCH
 ZCH
(@ZCH)
ゲスト
結合: 16年前
投稿: 25
 

依存によりZ.dllが複数に見えても、Z.dllのインスタンスは A.exe 内では
1つなのでグローバル変数は共有ですよ。
別々に存在させたい変数はZに置かない につきます。


返信引用
ITO
 ITO
(@ITO)
ゲスト
結合: 22年前
投稿: 1235
 

うーーん、
DLLはあくまでもライブラリーですからそれに基づいて考えないとまずいと思います。
動的なライブラリーというだけですね。
変数の共有はできても依存させたグローバル変数は原則的に作れない
と思ったほうがいいと思います。


返信引用
ITO
 ITO
(@ITO)
ゲスト
結合: 22年前
投稿: 1235
 

> それとも、スタティックライブラリのときのように別々に存在することも
> あり得るのでしょうか?
ん?
スタティックライブラリーは個別にリンクして作れるから依存できているだけですね。
例外はあると思います。
原則的にDLLの場合、リンクといっても単純に関数を呼び出すだけであり、
スタティックライブラリーのような複雑なリンクはできないと思ったほうがいい
とお思います。


返信引用
亀山
 亀山
(@亀山)
ゲスト
結合: 18年前
投稿: 133
Topic starter  

ご意見ありがとうございます。

EXE自身や、EXEがリンクしているDLLが、
各々自分自身でZ.dll内の変数にアクセスしても、
1つのアプリケーション内ではみな同じものになるのですね。

Z.dllに多くの「パラメータ」を持たせておき、
A.exeが起動時に自分自身のアプリに必要なものを設定し、
あちこちでよばれるZ.dll内の関数が各自でその値を使って動作する
ということができるか検討していたのですが、
それ自体はDLLの仕様上は可能ということがわかりました。
ありがとうございます。


返信引用
亀山
 亀山
(@亀山)
ゲスト
結合: 18年前
投稿: 133
Topic starter  

すみません、問題そのものは解決済みなのですが、
技術的な質問として追記させていただきます。

複数のDLL間でアプリケーション側の設定を参照したい場合、
今回のような方法でもよいものなのでしょうか?
もっと的確な方法はありますでしょうか?

今回の例では、1つのアプリケーション内で完結しているぶんには、
各関数がtheAppのメンバを見れば済むような話で、
感覚的には、プラグインとして分けたDLLが
アプリケーション側の設定を知りたいという状態なのですが、
どのようにして共有すべきなのでしょうか。


返信引用
仲澤@失業者
(@uncle_kei)
Prominent Member
結合: 5年前
投稿: 828
 

 自分的にはアプリケーションの各部が参照する共有データをDLLに持たせる
ことはしません。現在においては、DLLの意義はメモリーの節約のために利
用するというよりも、機能群の分離明確化やアップグレードの簡便化などに
重心が移動していると考えられます。その場合個々のDLLはより独立性を求め
られると考えられるため、なるべく依存関係が無く、できれば単体で利用可能
であることが望まれます。それによって、クリティカルでない共有フラグが
個々のDLLに重畳して存在することになっても、特に問題を感じません。
むしろ、共有フラグ設定のコードを個々のDLLのプロジェクト間で共有する方が
まし、とも考えられます。特にC++でコードする場合はその傾向が強く感じられ
ます。
 つまり、むしろ、未来にそのフラグを共有したくなくなった場合に発生する
コストの方が気になるわけです。


返信引用
ITO
 ITO
(@ITO)
ゲスト
結合: 22年前
投稿: 1235
 

仲澤さんと同意見です。
 もし共有データを持ちたいとすると、DLLではなくむしろ、そのDLLを使用する。
アプリケーション間で共有するのが筋だと思います。
 DLLは、動的なライブラリーでアプリケーションではないです。
ただ、動的なライブラリーなのでつけたりで出来ることがあるだけだと思います。
例外として、ウイルスワクチン、ノートPCの電源管理ソフトなどリアルタイム
で動いているソフトで必要な場合は考えなければいけないかも知れませんね。


返信引用
ITO
 ITO
(@ITO)
ゲスト
結合: 22年前
投稿: 1235
 

訂正です。

>  もし共有データを持ちたいとすると、DLLではなくむしろ、そのDLLを使用する。
> アプリケーション間で共有するのが筋だと思います。


>  もし共有データを持ちたいとすると、DLLではなくむしろ、そのDLLを使用する
> アプリケーション間で共有するのが筋だと思います。


返信引用
亀山
 亀山
(@亀山)
ゲスト
結合: 18年前
投稿: 133
Topic starter  

仲澤@失業者さん、ITOさん、ご意見ありがとうございます。

ちなみになのですが、

> DLLではなくむしろ、そのDLLを使用する
> アプリケーション間で共有するのが筋だと思います。

アプリケーションのプラグインとして機能するDLLが、
今回の自分の件のようにアプリケーション内の情報や設定値を参照したい場合、
どのようにしているのでしょうか。

アプリケーション自身が、そのようなインターフェイスを、
DLLと同じようにエクスポート関数として用意できるものなのでしょうか?


返信引用
subaru
 subaru
(@subaru)
ゲスト
結合: 19年前
投稿: 381
 

>アプリケーションのプラグインとして機能するDLLが、
>今回の自分の件のようにアプリケーション内の情報や設定値を参照したい場合、
>どのようにしているのでしょうか。

必要な情報だけを構造体にまとめて、
DLL側にある関数に引数として渡してやるとかではだめなんでしょうか。
DLL内に関数が多いのであれば、設定値を渡す用の関数を別に用意してもいいと思います。


返信引用
亀山
 亀山
(@亀山)
ゲスト
結合: 18年前
投稿: 133
Topic starter  

> 必要な情報だけを構造体にまとめて、
> DLL側にある関数に引数として渡してやるとかではだめなんでしょうか。
> DLL内に関数が多いのであれば、設定値を渡す用の関数を別に用意してもいいと思います。

やはりプラグインの機能を使っているアプリケーションは、
各プラグインの動作前に「自分の設定」を教えているのでしょうかね。
ご意見ありがとうございます。


返信引用

返信する

投稿者名

投稿者メールアドレス

タイトル *

プレビュー 0リビジョン 保存しました
共有:
タイトルとURLをコピーしました