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

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

ログ内検索

キーワードを複数指定する場合は半角スペースで区切ってください。
検索条件は、(AND)=[A かつ B] (OR)=[A または B] となっています。
[返信]をクリックすると返信ページへ移動します。

キーワード	/	検索条件	/
検索範囲	/	強調表示	/ ON (自動リンクOFF)
結果表示件数	/	記事No検索	/ ON
大文字と小文字を区別する

No.46048 の関連記事表示

ヒット / 1件

<< 0 >>

■46048

　Re[11]: コントロール・フォントスタイル変更時のFont解放について

□投稿者/ たくボン -(2010/01/23(Sat) 23:08:23)

■No46042 (なちゃさん) に返信
> ■No46041 (たくボンさん) に返信
>>■No46016 (なちゃさん) に返信
> >>■No45950 (たくボンさん) に返信
> >>プロパティを「リセット」すると、コンテナと同一のインスタンスになったりします。
> >>※リセットした場合はDisposeしてはだめですし、同じフォントを設定した場合はDisposeする必要があることになります。
>>
>>http://msdn.microsoft.com/ja-jp/magazine/bb985010.aspx
>>http://msdn.microsoft.com/ja-jp/library/b1yfkh5e(VS.80).aspx
>>http://msdn.microsoft.com/ja-jp/library/system.drawing.font.dispose(VS.80).aspx
>>フォントのリソースが解放されるタイミングはいつかな？
>
> いまいち何が言いたいのか意図がよく分かりません。
> 私が書いたことのどの部分に対して、何を言いたいのかはっきり書いてもらえないでしょうか？
>
> 私が書いた
> >>※リセットした場合はDisposeしてはだめですし、同じフォントを設定した場合はDisposeする必要があることになります。
> は、
> もしデザイナ上でリセットした場合はコンテナと同一のFormインスタンスが設定されているので、コントロール側で不要になっても勝手にDisposeなんか実行してはいけないし（コンテナ側ではまだ使用中）、
> リセットではなく同じフォントを設定したのなら、別インスタンスなのでコントロール側で不要になったらDisposeを実行しないといけない（コンテナ側では使用していない）、
> でもこんな風にデザイナでの操作で変わってしまうような動きなので、自分で作るプログラムでもきちんと管理できていないことが多いだろう、
> だから、フォントを変える時に（必要な場合のみ）Disposeを呼ぶというやり方は現実的にあまり安全ではないだろう
> ということです。

安全ではない？本当に？

> nullの代入は実質的には動作に影響はない（動作は変わりますが最終結果は変わらない）のでおいとくとして、
おいておくんだ。確かに最終結果は変わらないね。

> Disposeを呼べば、その時点でradioButtonAに設定されていたFontの（ネイティブな）リソースが解放されて、そのうえでSuppressFinalizeによりFinalize対象から外されます。
radioButtonA.Fontは外れるよね。これで次回のGCでは一応このFontがガベージ対象になるかもしれないって訳だ。

> ※もし、FontのインスタンスがコンテナのFontと同一のものなら、後で問題が発生する危険があるでしょう。
どんな問題だろう？リソースが解放されてしまう危険？

> Disposeを呼ばなければ、そのあとの別のフォントの代入によって参照が外れますので、その時点でGC「対象」になるでしょう。
確かにGC対象にはなるけどDisposeを明示的に呼ぶ場合と、呼ばなかった場合はFinalizeの動作が変わってこない？

> 次のGC時にファイナライズ対象になり、そのうちファイナライざスレッドでリソースが解放され、さらにその次のGC時にメモリ回収されるでしょう。
さて、ここで問題。ファイナライザメソッドが呼び出されるのはどのタイミングか？
ファイナライザが回収すべき（Finalizeメソッド）は、どこで管理されてて、いつ登録されるのか？

> ※もし、FontのインスタンスがコンテナのFontと同一のものなら、何もしないのと実質変わりません（コンテナからの参照が生きているため、GC対象にはならない）。
一応解ってるみたいだけど。

MSがGCを採用した背景には、ガベージで管理するメモリはピンキリのプログラマがいるから、そいつらなんかにメモリの管理なんかまかせてられないってのがあるのは周知の事実。（へっぽこプログラマのせいでOSのせいにされちゃかなわないから）

そこでClose、DisposeとFinalizeメソッドを用意したんだけど、これだけでも不安は残る。特にStringクラスに代表されるような頻繁に可変長になる領域や同一リソースの重複はGCにとって、あまり歓迎されるものでもない。これはWin32の頃からAtomとかで色々してたから、.NETでも同じようなしくみは用意してると思う（でないとわざわざStrngとStringBuilderを分けてないはず）

さらに言えば、システムで用意しているSystemColorやSystemBrushesのようなオブジェクトはプログラマに公開してリソースの節約を図りたいけど、Disposeされる危険もある。クラス設計者はDisposeが何度呼ばれても大丈夫なように設計してるはずだろうし、プログラマがDisposeを呼び出してくれることを期待してもいけない。

だからファイナライザとFリーチャブルキューの機能を設けて、参照されているオブジェクトの保護もしてるってこと。

Dsiposeしない場合は、不要なオブジェクトとマーキングされて、オブジェクトの回収の段階で完全キューからFリーチャブルキューを参照。FontオブジェクトはFinalizeを実装してるから、Fリーチャブルキューに入れて次回のGCで最終的なゴミと判断してFinalize。

> このように自分でプログラムを作成している時でも、この辺りのプロパティのインスタンスがどうなっているかは
> 結構分かりにくかったり、予想と違う動作をしていたりもしますので、はっきりいってあまりきちんと管理できて
> いないことの方が多いように思います。

まったくその通り。
管理ができないならGCにまかせておけばいいと思うよ。

そのためのウルトラマンだし。

下手にDisposeとFinalizeを書かれてたりしたら、悩む材料なだけだし（ひどく言えばバグのもとにもなる。今は内部的にどうなったかわからんけどVS2005の暗黙的なFormとかは、この手の問題を抱えてたから、GCされる時にDisposeしてたりしてたら実際バグる時もあったし。この手のバグはGCと絡むから追跡しにくいバグだし、設計がちゃんとしてれば問題なかったはず。）

これくらい言えばわかってもらえたかな？

わからなかったら
selectedFont = new Font
だけでいいと思う。メモリ管理はGCに任せておけばOK（そのためのGCだし）

記事No.45896 のレス /過去ログ78より / 関連記事表示
削除チェック/

<< 0 >>

パスワード/

- Child Tree -