ど〜も、中井です。 /['o'] （立て続けのメールで恐縮ですが．．．） デストラクターに関しては私も興味があるので、便乗させて いただきます。 最近のC++の（たぶんPerlでも）傾向としては、コンストラク ター＆デストラクターで（メモリーおよびその他の）資源の管 理を行うようになってきているようです。 （例えば、Closeせずに使われなくなったファイルも、デスト ラクターで確実にCloseする。等です） [ruby-dev:3527] Re: GC target (Re: [ruby-list:10035] Re: Ruby/Gtk text widget)で >GCの発生するのは > : > : > * file descriptorを使い切った時 と言うのは、こういったことに対応するためだとは思うのです が、世の中にはメインメモリーとファイル以外の（そのユーザー 特有の）資源を管理したい用途はあると思います。 その時にGC発生条件を増やしていく訳にはいかないと思います。 （もちろん、「自分でちゃんとClose相当の処理をしろよ」と言う のも解なのですが ruby 的な解ではないですよね。） 特に、組み込み系／リアルタイム系のシステムではメモリーに限 らず資源はケチケチなんですよね〜（ruby を組み込む余裕がない ほど．．．） そういった時に、参照カウント方式のメモリー管理って結構有用 なんですよ。 今更、ruby のメモリー管理方式を選択式にできるとは思っていま せんが、一応比較表のようなものを作って見ました。 （マーク・スイープ方式と比べた場合の）参照カウント方式の欠点 ・循環データを削除できない（←こいつは痛い！） ・全体に処理が重くなる。 ・ruby自体、および拡張モジュールを書く場合の手間が増える （これに関してはC++を使えば軽減出来そうですが移植性が…） （マーク・スイープ方式と比べた場合の）参照カウント方式の利点 ・開放タイミングが予測可能。 ・（開放タイミングに関連して）処理時間の予測が可能 ・（開放タイミングに関連して）資源の早期の開放が可能 ・ある日突然、GCが走って中断することがない と言ったところでしょうか、 リアルタイム処理の定義は、「処理時間が早い」ことではなくて、 「確実にある処理時間内に処理が終了する」ですので、参照カウン ト方式が向いています。 後、リアルタイムとは直接関係ないのですが、一般的にそのような 用途では資源がかなり限られていると言うのは前述した通りです。 いや〜、またしても ruby とはあまり関係ない話題をしてしまいま した。 それでは、失礼いたします。 民斗<tommy / valley.ne.jp> さんは書きました： >民斗です。 > >[Subject: [ruby-list:9959] デストラクタ(?)] >[Date: Sat, 10 Oct 1998 07:05:04 +0900 From:SEKI] > >> インスタンスが消滅するときに後始末をさせたいと思っています。 >> Ruby にはデストラクタ(?)のようなものはありますか? >> あるとすると、メソッド名は何とすればよいのでしょうか? > >以前、同じような質問([ruby-list:9018])をしたことがありまして、その時の >まつもとさんの回答([ruby-list:9026])は以下でした。 > >> |2. C++ のデストラクタのようなものは Ruby ではどのように書くのでしょうか。 >> | C での拡張モジュール中では、Data_Make_Struct() の第４引数で関数を指定 >> | できるようですが、Ruby で作成したクラスの場合、どのように書くのか >> | わかりませんでした。 >> >> RubyレベルではGCがあるので，明示的にオブジェクトを破棄する必 >> 要はあまりないはずです．どーしても，GCのタイミングでなんらか >> の処理が行いたい場合には lib/final.rb を使うワザはありますけ >> どね．実例としては lib/tempfile.rb を参照して下さい．でも， >> 分かるかなあ．必要でしたら更に解説します． > >-- >民斗 > -- T.NAKAI nakai / m1.sys.to.casio.co.jp