- 391 名前：デフォルトの名無しさん mailto:sage [04/09/23 19:04:22]
- >>368
継続はコールバックに跨らなければ問題ない。
ハンドラからtoplevelに直接行ったりきたりする様な継続の呼び出しは
不可能ではないけど、コールバックを叩くWindows側で何をしているのかわからんから、
こっちはやらない方が良いとは思う。
ちゃんとコールバックに制御を返却する当てがあるなら、たぶん問題なし。
これに関しては結局セオリーみたいのは見つからなかった。
(deine user32 (loadlib "user32.dll" ))
(define DefWindowProc (getproc user32 "DefWindowProcA" __stdcall '(h m w l)))
(define handler (make-callback __stdcall
(lambda (hwnd msg wparam lparam) (DefWindowProc hwnd msg wparam lparam))))
(define (single-window handler) (make-window handler))
自作の処理系ではこういう感じで窓を作成する。
make-callbackでクロージャとC関数をブリッジする以外に特別な物はない。
schemeの様に内部定義を許す言語のメリットはここから。
handlerはclosureそのものなので、関数外の局所変数をあえて引数渡しする必要がなく、
C言語だとグローバル変数に移したり関数で分離していた箇所を一つにまとめることができる。
(define (test foo)
(make-window (make-callback __stdcall (lambda (hwnd msg wparam lparam)
(display foo) ;; ハンドラ外の変数の参照
(DefWindowProc hwnd msg wparam lparam))
この辺の自由度はC言語と比べると比較にならない。（gccはExtensionで関数内関数が
使えるんだけど制限が多く、schemeの様に内関数同士の再帰やコールバック関数にできない。）
ただね、いまんとここれ使って何がしたいって訳でもないので、そのまま放置状態。
とにかく機構そのものより、ラッパとか書くのが面倒すぎて、型変換も適当。
|
 |
