[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[b-free: 726] Re: B-Free APの開発環境
塩澤です.
From: Takanori Hayashi <takanori@ohsaki.meidensha.co.jp>
Subject: [b-free: 725] Re: B-Free APの開発環境
Date: Tue, 04 Nov 1997 17:01:12 +0900
> そうするとシステム管理領域にユーザデータへのポインタを保持させておく
> ということになりますか。一見効率的ですけど、システムコールのコストを
> 考えるとユーザコード側でハッシュテーブル牽いた方が速くありませんか?
確かに,システム領域だとそうかも知れませんね.
いちいち,システムコールを呼ばないとならないとすると.
システムコールを変えることはできないでしょうし.
そう言われると,すべてのオブジェクトにthisポインタ領域を
持たせるのは,良くないかも知れません.
でも,event-drivenなコールバック関係の処理なら,
コールバックの時に,「ユーザコンテキストデータ」(仮称)を
コールバック関数の引数として返させることができます.
コールバックがあってから,コンテキストデータを得るために
システムコールを呼ぶのではなくて,コールバックのときに
同時に,あらかじめ登録してあったコンテキストデータも
得られるようにすればいいわけです.
Motif(X-Window)なんかだと,イベントごとに違う
(Cの)コールバック関数が登録できて,それぞれに,
ユーザ用のコンテキストデータも登録できます.
普通は,このデータは,同じようなボタンでコールバック関数を
供用するときに,押されたボタンを区別するために使われたり
するのですが,thisポインタ用に,もう1つあればどんなに
便利なことかと,いつも思っていたもので.
そのほかのものでも,「ハッシュ」ってのは,どうも.
MFCが,どんなハッシュ関数を使っているのか知らないのですが,
裸のWindows APIとMFCで,何もしないコールバック処理を
させると10倍ぐらいは処理数が違いませんでしたっけ(出典忘れ).
せめて,あるハッシュ関数で,完全ハッシュされることが
保証されてるオブジェクトIDにしてほしかった.
UNIXのファイルディスクリプタみたいに,プロセスごとに
小さい数から割り当てていくものなら,
変換テーブルも,小さな配列で大丈夫だったのに.
塩澤 秀和 shiozawa@myo.inst.keio.ac.jp