[#39106] What processor do you run ruby on? — "K.Sasada" <ko1@...>

 ささだです。

13 messages 2004/02/09
[#39200] Re: What processor do you run ruby on? — "K.Sasada" <ko1@...> 2004/02/17

"K.Sasada" <ko1@namikilab.tuat.ac.jp> wrote :

[#39207] Re: What processor do you run ruby on? — Isamu KOZUKA <kozuka@...> 2004/02/17

小塚@しなきゃならないテストがいっぱいだ〜....です。

[#39129] InternetExplorer ってインターフェースとして使える? — Shin-ichiro HARA <sinara@...>

原です。

34 messages 2004/02/10
[#39130] Re: InternetExplorer ってインターフェースとして使える? — Yac <yac@...> 2004/02/10

岡です。

[#39136] Re: InternetExplorer ってインターフェースとして使える? — Yac <yac@...> 2004/02/10

岡です。

[#39140] Re: InternetExplorer ってインターフェースとして使える? — arton <artonx@...> 2004/02/11

artonです。別件。

[#39144] Re: InternetExplorer ってインターフェースとして使える? — Shin-ichiro HARA <sinara@...> 2004/02/12

原です。

[#39145] Re: InternetExplorer ってインターフェースとして使える? — arton <artonx@...> 2004/02/12

artonです。

[#39146] Re: InternetExplorer ってインターフェースとして使える? — nobu.nakada@... 2004/02/12

なかだです。

[#39147] Re: InternetExplorer ってインターフェースとして使える? — arton <artonx@...> 2004/02/12

artonです。

[#39150] Re: InternetExplorer ってインターフェースとして使える? — nobu.nakada@... 2004/02/12

なかだです。

[#39151] Re: InternetExplorer ってインターフェースとして使える? — arton <artonx@...> 2004/02/12

artonです。

[#39275] DnD on win32 — Shinichiro HIDA <shinichiro@...>

飛田と申します。

21 messages 2004/02/26
[#39276] Re: DnD on win32 — たむらけんいち <sgs02516@...> 2004/02/26

たむらです。

[#39277] Re: DnD on win32 — Shinichiro HIDA <shinichiro@...> 2004/02/27

飛田です。

[#39278] Re: DnD on win32 — Itou-T15@... 2004/02/27

[#39288] 固有値、固有ベクトルの計算 — Masahiro Sato <msato@...>

19 messages 2004/02/27

[ruby-list:39167] Re: InternetExplorerってインターフェースとして使える?

From: arton <artonx@...>
Date: 2004-02-12 17:07:02 UTC
List: ruby-list #39167
artonです。

On Fri, 13 Feb 2004 01:35:05 +0900
nobu.nakada@nifty.ne.jpさん wrote:

> GCとハッシュとの兼ね合いからです。
> 
> (1) Win32OLEIDispatchを共有するために、オブジェクトから
>     Win32OLEIDispatchへのテーブルが必要。
> 
> (2) オブジェクトを区別するために、値ではなくてIDをキーにしたい。
> 
> (3) しかしGCのためには、FixnumではなくてVALUE自体が必要。
> 
> (4) Win32OLEIDispatchはrubyオブジェクトではないので、GCでmarkし
>     てはいけない。
> 
> (5) キーと値のペア両方をmarkする関数はあるが、キーだけをmarkす
>     る関数は提供されていない。
> 
> という条件から、キーを整数として扱うtype_numhashを使う、ポイン
> タと見なされないようにFIXNUM_FLAGを立てておく、という方法を取っ
> ています。
うーん、わかったようなわからないような。
ruby-list:39161からの抜粋になりますが、*で示したものでも良いのではないで
しょうか?

 struct oledata {
@@ -234,6 +235,5 @@ static ULONG ( STDMETHODCALLTYPE Release
     ULONG u = --(p->refcount);
     if (u == 0) {
-	free(p->dispatch.lpVtbl);
-	rb_hash_delete(com_hash, ULONG2NUM((ULONG)p));
+	st_delete(DATA_PTR(com_hash), p->obj, 0);
*       rb_hash_delete(com_hash, p->obj);
 	free(p);
     }
@@ -308,18 +308,18 @@ val2dispatch(val)
     VALUE val;
 {
+    struct st_table *tbl = DATA_PTR(com_hash);
     Win32OLEIDispatch* pdisp;
-    IDispatchVtbl* p = ALLOC(IDispatchVtbl);
 ... snip ...
-    pdisp->obj = val;
-    rb_hash_aset(com_hash, ULONG2NUM((ULONG)pdisp), val);
+    st_data_t data;
+
+    if (st_lookup(tbl, val, &data)) {
+	pdisp = (Win32OLEIDispatch *)(data & ~FIXNUM_FLAG);
+    }
+    else {
+	pdisp = ALLOC(Win32OLEIDispatch);
+	pdisp->dispatch.lpVtbl = &com_vtbl;
+	pdisp->refcount = 1;
+	pdisp->obj = val;
+	st_insert(tbl, val, (VALUE)pdisp | FIXNUM_FLAG);
+    }
*    VALUE v = rb_hash_aref(com_hash, val);
*    if (v != Qnil) {
*       pdisp = (Win32OLEIDispatch *)(v & ~FIXNUM_FLAG);
*    } else {
*       ... snip...
*       rb_hash_aset(com_hash, val, (VALUE)pdisp | FIXNUM_FLAG);
*    }
     return &pdisp->dispatch;
 }
@@ -5408,5 +5408,13 @@ Init_win32ole()
     rb_global_variable(&ary_ole_event);
     id_events = rb_intern("events");
-    com_hash = rb_hash_new();
+
+    ... snip ...
+    com_hash = Data_Wrap_Struct(rb_cData, rb_mark_hash, st_free_table, st_init_numtable());
*    com_hash = rb_hash_new();
     rb_global_variable(&com_hash);

知りたいことは、この場合(*で示したように記述した場合)、キーとしてVALUE
(Objectのインスタンス)、値としてFIXNUMの普通のHashが登録されているという
状態ですが、これがまずいのかどうかです。僕は、ハッシュがグローバルなので
マーク対象となり、エントリーのキーもマークされるから問題ないと思っている
んですが。
別の理由としては、直接Rubyの内部インターフェイスに近いst_xxxを使うより、
インタープリタ自体の関数であるrb_hash_xxxxを使ったほうがRubyのバージョン
の変更に強いのではないかということです。たとえば、Hashのソースをst.cから
変える可能性のほうが(たとえばpublic domainでは実はなかった問題とか起きた
と仮定してください。あるいはもっと高速な実装を手に入れたとか)hash.cの関数
が変わる可能性より大きいだろうということです。

-- 
arton <artonx@yahoo.co.jp>

__________________________________________________
Do You Yahoo!?
http://bb.yahoo.co.jp/


In This Thread