vcpp-ml

31

[vcpp 00061021] RE: #import を使用して Access2002 を利用する方法について

島野です。

>  コンパイラ COM サポートよりはレガシな方法ですが、コレでは駄目でしょう
> か?

ダメということはありませんが、今回は #import を使ったやり方が
知りたかったもので・・・。

もしかしたら、Office をオートメーションする場合は、
ClassWizard を使うやり方のほうが一般的なのでしょうか?
マイクロソフトの KB にも、この方法しか紹介されていないようですし。

■ [HOWTO] MFC およびタイプ ライブラリを使用してオートメーション プロジェクトを作成する方法 
http://support.microsoft.com/default.aspx?scid=kb;ja;178749

# どうでもいいですが、[vcpp 00061016] のメールに誤字がありましたので
# 訂正しておきます。

# (誤)自身がありません。
# (正)自信がありません。

# です。

以上
--
31

[vcpp 00061020] Re: メモリマップトファイルでマッピング済みの領域の拡張

さあもとです。

[vcpp 00061018] S.Suzuki wrote:
> #しかし、動的に増えるメモリ領域の共有ってみんなどうやってるのでしょうか?

私も以前ページングファイルでの拡張ができないか試行錯誤してみ
たんですが、駄目そうだったので諦めますた(^^;)
管理するデータが比較的小さなものでしたので、あらかじめ大きめ
の領域を確保してお茶を濁してしまいましたが…。
何か方法がないものですかねぇ。

# 全く参考にならなくて申し訳ないです。m(_ _)m

~~~~~~~~~~~~~~~~~~~~~~~~~~
  へ  へ    さあもと
  の  の    E-Mail : s...@deneb.freemail.ne.jp
~~~~~~~~~~~~~~~~~~~~~~~~~~
31

[vcpp 00061019] Re: メモリマップトファイルでマッピング済みの領域の拡張

おはよございます。
またはずしましたか・・・(^^;

> 元メールのように、後から強引に伸ばしたマッピングエリアに対しても
> ほかのマッピングと共有している部分(メールの例では先頭100バイト)
> に関しては(きっちり排他処理を行っていれば)
> 通常のマッピングと同様に読み書きができて、メモリ共有手段としても
> 扱えるのか?
> ということだったのですが。。。
なるほど。

たとえば、普通にオープンするファイルだった場合に他のプロセスがファ
イルのサイズを変えると、別のオープン済みのプロセスは変化したサイズ
までファイルポインタをシークできるはずですよね。
これと同じようなメカニズムではないでしょうか?
ファイルマッピングオブジェクトとはいえ、プログラムから直接ファイル
にアクセスするのではなく、OS内部のキャッシュが実施されているはずで
す。なので、一方のプロセスではたぶん範囲外だろうあたりのオフセット
を指定されてもキャッシュ更新時に同期を取るだろうから、ご要望のこと
はOSとして「できなければならない」ことではないかと。

> うーむ。
> ページファイルではだめだった私のサンプルがおかしいかのせいもあるので
> また、ちょっと調べてみます。
なるほど。第一引数NULLだったらうまくいかなかったということですね?
この場合、ファイルとしてというより共有メモリとしての機能ですし、
うまくいくと思うんだけどなぁ・・・

増殖させる大きさをOSのキャッシュサイズより大きくしたりして実験すると
可・不可の判断ができるような気がしますが・・・σ(^_^)はできると思いま
すね。
#時間がないのでテストできませんが・・・

Win32だと、ネットワーク越えのプロセス間では保証していないとかいう
ことがどこかに書いてあったような・・・あれは別の話だったかな・・・
(遠い目)

是非結果を教えてくださいませ。
#でもって、σ(^_^)が間違っていた場合は、ごめんなさい。(^^;
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ Y.Uchiyama _/_/
_/private:
_/  HANDLE ゆーち;
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
記事検索
Amazon.co.jp
  • ライブドアブログ