- PR -

アンマネージのC++でメンバクラスをもちつつ、VBから利用できるソフトの作り方

1
投稿者投稿内容
チキン
会議室デビュー日: 2005/03/15
投稿数: 11
投稿日時: 2005-03-26 09:03
いま、作っているソフトで、基本の仕組みとして、特殊なデータベースが必要なのですが、どういう形でくみ上げていくかテスト中です。なお、本来のアプリケーションは、VBで概略出来上がってデータがメモリ上のみなら速度もなんとか合格しています。次に、2〜100GB程度のデータを256MBクラスのマシンでそこそこの効率で処理できればOKなのですが、アプリの性格を利用した特殊DBを作ると簡単に解決できそうと、踏んでいます。
その場合の構成を思案中なのですが、ご意見をお願いします。
１案
VB→マネージC++→[DLLImport]→アンマネージC++
＜良い点＞：
○マーシャリング機能が使える。（今回は、渡すデータが限られているので、MSの用意しているマーシャリング機能は使わなくて済む。）
○将来、マネージC++とアンマネージC++の関係が変わっても、[DllImport]ではっきりと区切られているので、MSが差異を吸収する仕組みを提供してくれる可能性が大きい。
○もしかしたら、アンマネージC++で、Staticであればメンバークラスを使える。（この辺が分かっていないのですが、メンバクラスをもつアンマネージクラスをVBから使えるようにするにはどうしたら、いいのでしょうか？）
＜悪い点＞
○[DLLImport]部分で、2.8Gのマシンで20MSくらい直接Callよりも余分にかかる。
（直接のCallは１MS程度と思われる）、[DllImport]の使用は何百万回程度のLoopの中では耐えられない。したがって、アンマネージ部分を極大化して、[DllImport]を減らさないといけない。すると、アンマネージDLLの中で、クラスを定義して使ったりできるのか（Staticの制限つきであれ）実際のところがわかっていなくて、教えていただきたいところです。

2案
VB→マネージC++→アンマネージC++　[DllImort]を使わないという意味です
＜良い点＞
○マネージから、アンマネージの関数を呼ぶ時間が短い。
○VBからはマネージC++はDLLというものの、実際はフルに、メンバークラスをもち、あたかも通常のアプリのように、プログラムできるので、ある程度の規模のソフトを作る場合に、急に関数思考の、昔戻りを強要されないですむ。
＜悪い点＞
○マネージからアンマネージを呼ぶ時間は短いといっても、アンマネージのプログラム間でのCall時間に比して非常に長いのかも知れない。（測定すれば分かりますが、理論的に分かるほうがありがたいので、ご存知の方あれば、レスお願いします）
○将来マネージとアンマネージの関係が変わった時に、すべてを見直さないといけない。変わる理由は、マネージC++が変わる（MSのVersionUp)、およびアンマネージC++が変わる（たとえば、ボーランドやインテルのC++への私の乗り換え）こちらの場合でも、[DllImport]相当の仕組みを自分（と言うより、たとえばインテルが提供するソフト）で且つ20MSも時間を使って、置き換えることで、乗り換え問題が解決可能です。
○アンマネージの側で、メンバークラスを持つことは、不可能と思います、すこしやってみましたが、Staticな変数でも、スコープがマネージとアンマネージにわたってしまうため、キチンと定義しきれないと思いました。そのため、アンマネージ側はクラスというより、関数思考で開発が必要です。したがって、断片的な処理（たとえば100MBのバファーを0で埋めるなど）をアンマネージ側でさせることになります。
案３
VB→メモリ→別プロセスのマネージC++とアンマネージC++の組み合わせ。
＜良い点＞
○DLLにまつわる、諸問題が一切ない。通常、DBはこの形に似た形で提供されており一般的。
＜悪い点＞
○仕組みがすこし複雑になる。
○VBからのCall時間がかかりそうに思われる。
どなたか、このあたりで、非常に高速IPCの仕組みをヒントいただけるとありがたいです。
以上、一番の疑問はアンマネージのC++でメンバクラスをもちつつ、VBから利用できるソフトの作り方ということで、どんなご経験でも、直感でも、ヒントいただけるとありがたく、よろしくお願いします。

1

スキルアップ／キャリアアップ（JOB@IT）