読者です 読者をやめる 読者になる 読者になる

デリゲートの遅延

 PHPによるラムダとクロージャの実装で、その役割を終える予感がビンビンするデリゲート。が、デリゲートにはまだ隠された魅力があることをご存知ですか。

 デリゲートまわりは遅延機能が旨みにある。例えば、動的リンクが成立しない状況でも、成立するまでリンク操作を遅延させる(シンボルの遅延解決)デリゲートマネージャがそうだし、そもそも関数ポインタ系自体が遅延評価に使える。惜しむらくは XOOPS Cube のデリゲートはマルチキャストのため戻り値が取れず、計算に組み込みにくいことだが……

 遅延の中でも個人的に使い勝手がいいと思っている特性が、デリゲートは登録する関数アドレス自体の解決を add 時に行わず、 call 時まで引き伸ばすこと。もちろん、静的な関数に限るが、 add 時にその関数がオンメモリでなくても add 自体は処理される(!)。そればかりか、ファイルを指定しておくと call 時にファイルを読み込んで関数アドレスを解決する機能まで入っている。これがかなり強力。同じことを C++ と DLL でやったら相当死ねます。

 この機能とデリゲートマネージャを組み合わせると、デリゲートと関数の両方がオンメモリではない状況でも結合を成立させることができる。この場合、デリゲートが宣言されたときに add が実行されるが、中身の評価は保留。 call の際に add の内容が評価されて、最後にコールバックが実行される。

 デリゲートは通常の関数ポインタ系の処理と比べれば重いが、デリゲートや、そこに登録する関数の宣言へPCがリーチしなくても動くので、この遅延特性を使いこなせば、 MOD 製作用にデリゲートを追加したり、その MOD でデリゲートにガンガン関数を登録しても、負荷への影響はほとんどない。