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

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

C# と VB.NET の入門サイト

Re[13]: eventについて


(過去ログ 28 を表示中)

[トピック内 16 記事 (1 - 16 表示)]  << 0 >>

■13141 / inTopicNo.1)  eventについて
  
□投稿者/ nori (1回)-(2008/01/25(Fri) 00:22:17)

分類:[.NET 全般] 

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

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

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

よろしくお願いします。

引用返信 編集キー/
■13147 / inTopicNo.2)  Re[1]: eventについて
□投稿者/ επιστημη (797回)-(2008/01/25(Fri) 00:48:48)
επιστημη さんの Web サイト
> フォームを閉じる場合、解除してあげる必要はないのでしょうか?

必要ありません。
フォームがなくなればイベントの発生元であるbuttonもなくなりますから。

引用返信 編集キー/
■13148 / inTopicNo.3)  Re[1]: eventについて
□投稿者/ やじゅ (41回)-(2008/01/25(Fri) 00:50:45)
やじゅ さんの Web サイト
2008/01/25(Fri) 01:05:15 編集(投稿者)

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

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

編集後記
かぶった、えぴさんより、1分程遅かったんです。
引用返信 編集キー/
■13220 / inTopicNo.4)  Re[2]: eventについて
□投稿者/ nori (2回)-(2008/01/25(Fri) 22:10:54)
ご回答ありがとうございます

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

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

理解できていない所があり、的を射てない質問になっているかも知れませんがご容赦願います。
引用返信 編集キー/
■13221 / inTopicNo.5)  Re[3]: eventについて
□投稿者/ επιστημη (799回)-(2008/01/25(Fri) 22:14:35)
επιστημη さんの Web サイト
> ガベージコレクションが走ったとしても
>   親フォーム→ボタン(のクリックイベントで)参照されている。
>   ボタン  →親フォームから参照されている?
> のような事になり、メモリ解放されないと言う事はないのでしょうか?

相互参照してダンゴになってたとしても、
そのダンゴがどこからも参照されなくなったら
ダンゴごと廃棄されます。安心めされい。

引用返信 編集キー/
■13225 / inTopicNo.6)  Re[4]: eventについて
□投稿者/ nori (3回)-(2008/01/25(Fri) 23:28:57)
ご回答ありがとうございます。

> 相互参照してダンゴになってたとしても、
> そのダンゴがどこからも参照されなくなったら
> ダンゴごと廃棄されます。安心めされい。
なるほど!
双方参照されなくなれば、ちゃんと解放されるのですね。
安心しました。
解決済み
引用返信 編集キー/
■13226 / inTopicNo.7)  Re[4]: eventについて
□投稿者/ やじゅ (47回)-(2008/01/25(Fri) 23:34:39)
やじゅ さんの Web サイト
GCアルゴリズム詳細解説
http://wiki.livedoor.jp/author_nari/d/GC
引用返信 編集キー/
■13312 / inTopicNo.8)  Re[5]: eventについて
□投稿者/ nori (4回)-(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が走った時点でメモリ解放されアクセスバイオレーションとなる危険なコードなのでしょうか?

中々奥が深くて難しいですね。

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

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

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

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

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

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

その疑問、不信感はとても重要で、忘れてはいけないと私は思いますが、
突き詰めるにはそれなりに蓄積が必要ですので、
「当面置いといて」、分かった気になって使うのがよいと思います。
引用返信 編集キー/
■13320 / inTopicNo.10)  Re[7]: eventについて
□投稿者/ nori (5回)-(2008/01/27(Sun) 00:04:24)
ご回答ありがとうございます。

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

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

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

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

皆様お忙しい中、回答をどうもありがとうございました。
解決済み
引用返信 編集キー/
■13331 / inTopicNo.11)  Re[8]: eventについて
□投稿者/ えムナウ (111回)-(2008/01/27(Sun) 17:46:16)
これってどういうケースなんでしょうかね?
http://msdn.microsoft.com/msdnmag/issues/07/11/CLRInsideOut/default.aspx?loc=jp#S5
http://msdn2.microsoft.com/ja-jp/library/aa970850.aspx
引用返信 編集キー/
■13332 / inTopicNo.12)  Re[9]: eventについて
□投稿者/ 渋木宏明(ひどり) (640回)-(2008/01/27(Sun) 18:29:44)
渋木宏明(ひどり) さんの Web サイト
> これってどういうケースなんでしょうかね?

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

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

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

そういうケースはあまり経験がないです。
引用返信 編集キー/
■13334 / inTopicNo.14)  Re[11]: eventについて
□投稿者/ 渋木宏明(ひどり) (641回)-(2008/01/27(Sun) 20:49:52)
渋木宏明(ひどり) さんの Web サイト
> static イベントだけなんでしょうか?

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

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

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

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

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

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

で、参照が残っていればオブジェクトインスタンスは存命する、と。

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

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

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

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

つまり、プログラマーはイベント割り当ての削除をしないとメモリーリークするケースを把握しておかなきゃいけないわけですよね。
引用返信 編集キー/
■13343 / inTopicNo.16)  Re[13]: eventについて
□投稿者/ 渋木宏明(ひどり) (642回)-(2008/01/28(Mon) 09:59:32)
渋木宏明(ひどり) さんの Web サイト
2008/01/28(Mon) 12:02:40 編集(投稿者)

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

ですよ。

最初に書いてますが

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

なんです。

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

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

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

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

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

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

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

そのとおりです。

引用返信 編集キー/


トピック内ページ移動 / << 0 >>

このトピックに書きこむ

過去ログには書き込み不可

管理者用

- Child Tree -