C# と VB.NET の質問掲示板

ASP.NET、C++/CLI、Java 何でもどうぞ

ログ内検索
  • キーワードを複数指定する場合は 半角スペース で区切ってください。
  • 検索条件は、(AND)=[A かつ B] (OR)=[A または B] となっています。
  • [返信]をクリックすると返信ページへ移動します。
キーワード/ 検索条件 /
検索範囲/ 強調表示/ ON (自動リンクOFF)
結果表示件数/ 記事No検索/ ON
大文字と小文字を区別する

No.13141 の関連記事表示

<< 0 >>
■13141  eventについて
□投稿者/ nori -(2008/01/25(Fri) 00:22:17)

    分類:[.NET 全般] 

    eventについて質問があります。

    例えば、ボタンのクリック時のeventを追加した場合下記のようなコードが追加されます。
    this.button.Click += new System.EventHandler(this.button_Click);

    上記は。ボタンのクリックeventに追加しているのは分るのですが、
    フォームを閉じる場合、解除してあげる必要はないのでしょうか?

    よろしくお願いします。
親記事 /過去ログ28より / 関連記事表示
削除チェック/

■13148  Re[1]: eventについて
□投稿者/ やじゅ -(2008/01/25(Fri) 00:50:45)
>
    2008/01/25(Fri) 01:05:15 編集(投稿者)

    No13141 (nori さん) に返信
    > eventについて質問があります。
    >
    > 例えば、ボタンのクリック時のeventを追加した場合下記のようなコードが追加されます。
    > this.button.Click += new System.EventHandler(this.button_Click);
    >
    > 上記は。ボタンのクリックeventに追加しているのは分るのですが、
    > フォームを閉じる場合、解除してあげる必要はないのでしょうか?
    >

    フォームを閉じるならボタンも削除されるし、別に解除しなくてもいいんでないの

    編集後記
    かぶった、えぴさんより、1分程遅かったんです。
記事No.13141 のレス /過去ログ28より / 関連記事表示
削除チェック/

■13147  Re[1]: eventについて
□投稿者/ επιστημη -(2008/01/25(Fri) 00:48:48)
>
    > フォームを閉じる場合、解除してあげる必要はないのでしょうか?

    必要ありません。
    フォームがなくなればイベントの発生元であるbuttonもなくなりますから。
記事No.13141 のレス /過去ログ28より / 関連記事表示
削除チェック/

■13220  Re[2]: eventについて
□投稿者/ nori -(2008/01/25(Fri) 22:10:54)
    ご回答ありがとうございます

    解除不要との事ですが、この場合メモリリークの心配は不要なのでしょうか?
    GCがメモリ管理をしていると言うのは目にするのですが、一体どういった方法で管理しているのかがどうも理解できないです。

    ガベージコレクションが走ったとしても
      親フォーム→ボタン(のクリックイベントで)参照されている。
      ボタン  →親フォームから参照されている?
    のような事になり、メモリ解放されないと言う事はないのでしょうか?

    理解できていない所があり、的を射てない質問になっているかも知れませんがご容赦願います。
記事No.13141 のレス /過去ログ28より / 関連記事表示
削除チェック/

■13221  Re[3]: eventについて
□投稿者/ επιστημη -(2008/01/25(Fri) 22:14:35)
>
    > ガベージコレクションが走ったとしても
    >   親フォーム→ボタン(のクリックイベントで)参照されている。
    >   ボタン  →親フォームから参照されている?
    > のような事になり、メモリ解放されないと言う事はないのでしょうか?

    相互参照してダンゴになってたとしても、
    そのダンゴがどこからも参照されなくなったら
    ダンゴごと廃棄されます。安心めされい。
記事No.13141 のレス /過去ログ28より / 関連記事表示
削除チェック/

■13226  Re[4]: eventについて
□投稿者/ やじゅ -(2008/01/25(Fri) 23:34:39)
>
記事No.13141 のレス /過去ログ28より / 関連記事表示
削除チェック/

■13225  Re[4]: eventについて
□投稿者/ nori -(2008/01/25(Fri) 23:28:57)
    ご回答ありがとうございます。

    > 相互参照してダンゴになってたとしても、
    > そのダンゴがどこからも参照されなくなったら
    > ダンゴごと廃棄されます。安心めされい。
    なるほど!
    双方参照されなくなれば、ちゃんと解放されるのですね。
    安心しました。
記事No.13141 のレス / END /過去ログ28より / 関連記事表示
削除チェック/

■13312  Re[5]: eventについて
□投稿者/ nori -(2008/01/26(Sat) 22:54:48)
    >GCアルゴリズム詳細解説
    >http://wiki.livedoor.jp/author_nari/d/GC
    素晴らしいサイトのご紹介ありがとうございます
    こんなに色々なアルゴリズムが存在するとは思っていませんでした。
    正直ビックリです。
    
    基本的には、オブジェクトの参照が切れたら解放されると言う事ですね。
    唯、オブジェクトの参照が切れている状態が、曖昧で分り難いと思いました。
    
    例えば以下のような場合。
    public void Test()
    {
        Hoge o = new Hoge ();
    }
    このような場合は、関数を抜ければHogeクラス(変数o)の参照が切れる事は理解できるのですが
    
    public void Test2()
    {
        Hoge o = new Hoge();
        this.hogeEvent += new EventHandler(o.handler);  // イベントに登録
    }
    
    上記のような場合はどうなのでしょうか?
    Test2関数を抜ければ、Hogeクラス(変数o)自体にはもうアクセスできませんが、
    hogeEventからは、handler関数が呼ばれる為、参照は切れていないと言う判定になるのでしょうか?
    それとも、参照が切れていると言う判定になり、GCが走った時点でメモリ解放されアクセスバイオレーションとなる危険なコードなのでしょうか?
    
    中々奥が深くて難しいですね。
記事No.13141 のレス /過去ログ28より / 関連記事表示
削除チェック/

■13315  Re[6]: eventについて
□投稿者/ れい -(2008/01/26(Sat) 23:18:59)
    No13312 (nori さん) に返信
    > それとも、参照が切れていると言う判定になり、GCが走った時点でメモリ解放されアクセスバイオレーションとなる危険なコードなのでしょうか?

    いいえ。
    ちゃんと参照アリとして数えてくれます。
    たくさんの人がチェックしてますから、殆ど「抜け」は無いと思います。

    > 唯、オブジェクトの参照が切れている状態が、曖昧で分り難いと思いました。

    そうですね。
    自分で管理するのが当たり前の世界にいた人には、
    気持ち悪いしわかりづらいと感じるのも当然だと思います。

    GCが出始めのころは、そういった議論がよくありました。
    また、上に出てきた「抜け」がたまにあったりして、大問題になったりしました。

    .NetのGCに問題が全く無いわけではないようですが、
    大抵の場合は深く考えなくてもきちんと動いてくれます。

    その疑問、不信感はとても重要で、忘れてはいけないと私は思いますが、
    突き詰めるにはそれなりに蓄積が必要ですので、
    「当面置いといて」、分かった気になって使うのがよいと思います。
記事No.13141 のレス /過去ログ28より / 関連記事表示
削除チェック/

■13320  Re[7]: eventについて
□投稿者/ nori -(2008/01/27(Sun) 00:04:24)
    ご回答ありがとうございます。

    >いいえ。
    >ちゃんと参照アリとして数えてくれます。
    >たくさんの人がチェックしてますから、殆ど「抜け」は無いと思います。
    参照アリと判断されるのですね。
    さらに理解&安心できました!

    ありがとうございました。

    >そうですね。
    >自分で管理するのが当たり前の世界にいた人には、
    >気持ち悪いしわかりづらいと感じるのも当然だと思います。
    そうなんです。
    自分はC++派なので、正直気持ち悪くて・・・
    せめてメモリーリークしてるよ!って教えてくれたらいいのですが、なかなか難しいですね。

    とりあえず、安心できました。
    後は、やじゅさんにご紹介頂いたサイトを見て、GCのパターン(アルゴリズム)を勉強しておこうと思います。

    皆様お忙しい中、回答をどうもありがとうございました。
記事No.13141 のレス / END /過去ログ28より / 関連記事表示
削除チェック/

■13331  Re[8]: eventについて
□投稿者/ えムナウ -(2008/01/27(Sun) 17:46:16)
記事No.13141 のレス /過去ログ28より / 関連記事表示
削除チェック/

■13332  Re[9]: eventについて
□投稿者/ 渋木宏明(ひどり) -(2008/01/27(Sun) 18:29:44)
>
    > これってどういうケースなんでしょうかね?

    「WeakEvent パターンを実装する理由」の項に書かれているとおりです。

    「Form が、自身に配置されている Control のイベントを受け取るだけ」のようなごく簡単なシナリオ *以外* では、イベント接続は明示的に接続解除を行わないとダメなんです。
記事No.13141 のレス /過去ログ28より / 関連記事表示
削除チェック/

■13333  Re[10]: eventについて
□投稿者/ えムナウ -(2008/01/27(Sun) 19:24:29)
    static イベントだけなんでしょうか?
    それともLifeの長いオブジェクトの話も含まれるのかな。

    そういうケースはあまり経験がないです。
記事No.13141 のレス /過去ログ28より / 関連記事表示
削除チェック/

■13334  Re[11]: eventについて
□投稿者/ 渋木宏明(ひどり) -(2008/01/27(Sun) 20:49:52)
>
    > static イベントだけなんでしょうか?

    static イベント限定の話ではありません。

    > それともLifeの長いオブジェクトの話も含まれるのかな。

    長短ではなく、「イベントリスナよりもイベントソースの寿命が長い場合」の話です。

    イベントソースはイベントハンドラへの参照を保持しています。
    (ただし、イベントソースへの参照がすべて失われれば、その時点でイベントソースからイベントハンドラへの参照も失われます)

    イベントハンドラがインスタンスメソッドであれば、イベントハンドラは元になるオブジェクトインスタンス(=イベントリスナ)への参照を保持します。
    イベントハンドラへの参照が維持されている限り、イベントリスナへの参照も維持されるわけです。

    なので、一見イベントリスナへの参照がすべて失われたように見えても、イベントソースが存命である限り「イベントソースからイベントハンドラへの参照」が残っているため、「イベントハンドラからイベントリスナへの参照」も残るわけです。

    で、参照が残っていればオブジェクトインスタンスは存命する、と。
記事No.13141 のレス /過去ログ28より / 関連記事表示
削除チェック/

■13337  Re[12]: eventについて
□投稿者/ えムナウ -(2008/01/28(Mon) 02:26:46)
    >イベントリスナよりもイベントソースの寿命が長い場合
    はい、それは書いてあるし理解はできるんですが。
    結果的に不要になったイベントリスナにも影響が出るのはわかります。

    現実路線として結局プログラマーは何を気にしなきゃいけないんだろうと思いまして。

    イベントソースの寿命を気にしてイベントつけなきゃいけないんなら、
    クラスの寿命をしっかり書いてある仕様書もらわなきゃForm内じゃないところへのイベント割り当てはできなくなる。

    Form内からForm内じゃないところへのイベント割り当てをしたらFormまたは管理できるところのDisposeで削除するべきだということですね。
    Form外のクラスから自分に含まれないクラスにイベント割り当てをしたら自クラスのDisposeで削除するべきだということですね。

    つまり、プログラマーはイベント割り当ての削除をしないとメモリーリークするケースを把握しておかなきゃいけないわけですよね。
記事No.13141 のレス /過去ログ28より / 関連記事表示
削除チェック/

■13343  Re[13]: eventについて
□投稿者/ 渋木宏明(ひどり) -(2008/01/28(Mon) 09:59:32)
>
    2008/01/28(Mon) 12:02:40 編集(投稿者)

    > イベントソースの寿命を気にしてイベントつけなきゃいけないんなら、
    > クラスの寿命をしっかり書いてある仕様書もらわなきゃForm内じゃないところへのイベント割り当てはできなくなる。

    ですよ。

    最初に書いてますが

    >「Form が、自身に配置されている Control のイベントを受け取るだけ」のようなごく簡単なシナリオ *以外* では、イベント接続は明示的に接続解除を行わないとダメなんです。

    なんです。

    > Form内からForm内じゃないところへのイベント割り当てをしたらFormまたは管理できるところのDisposeで削除するべきだということですね。
    > Form外のクラスから自分に含まれないクラスにイベント割り当てをしたら自クラスのDisposeで削除するべきだということですね。

    Dispose() が適切なタイミングであるかどうかはシナリオによって異なります。

    Windows.Forms/WPF や IDisposable とはまったく関係のないクラス/クラス間でも、イベント接続は利用可能ですし。

    「イベントリスナは、イベント接続が不要になった時点でイベント接続を解除するのが大原則」としておくべきでしょう。

    例外は、イベントソースとすべてのイベントリスナがほぼ同時期にすべての参照を失うような場合です。

    このスレの最初の投稿で挙げられた例は、たまたまそれに合致しているだけです。

    > つまり、プログラマーはイベント割り当ての削除をしないとメモリーリークするケースを把握しておかなきゃいけないわけですよね。

    そのとおりです。
記事No.13141 のレス /過去ログ28より / 関連記事表示
削除チェック/



<< 0 >>

パスワード/

- Child Tree -