memo/20070423

ガベージコレクションについてメモ

項目	メモ
参照カウント型	循環参照問題を解決できない
マーク＆スイープ型
ジェネレーション型

D言語はGC型言語だそうで...

私は勉強不足なのか、GCに懐疑的。

確かに、メモリ管理コードを書きたくないとか、使い捨てプログラムばかりを書いているプログラマにとってはいいかもしれない。

でもプロが書くべきプログラムはそんな使い捨ての領域じゃなくて、最低速度保障が求められたり、連続運転の安定性が求められる領域じゃないの？

誰でも一定以上の技術で釘が打てるツールは、確かに有用だと思う。
だけど、そのツールでどういうビジネスをやるか。
単価の安い大工をたくさん集めて、共通のコミュニケーション言語もあやふやな状況で、粗悪品を大量生産する方向に向かいはしないか。

私はGCやメモリ管理について勉強不足なのだろうか？


うーむ。とりあえず
GC.SuppressFinalize(this)をいつ呼ぶべきで、いつ呼んではいけないのかが、いまだに腑に落ちていないし、「マネージドリソース」を一言で言い切る説明をいまだに見つけられないし...とにかく簡単ではないということはわかった。

.Net 言語の開放処理の本質を理解するには、言語を超えて .Net を理解しないと難しいらしい。
デストラクタ、ファイナライザ、Disposeメソッド、Closeメソッドなど複数のメソッドがある意味、またデストラクタやファイナライザの意味が C#、VB、マネージドC++等、各言語で異なる理由、GC が必要とされる背景がどのようなものなのかなど。
ハードルはそれなりに高い。
例の「自分ならどう実装するかを自分自身で考えないと真には理解できない」問題に帰着している。

言語設計者の甘言通りのプログラミング環境(明示的に開放する言語を使うより速くて安全なプログラムを誰でも作れる)にはならないと思う。

「.Netの中の人」がどう動いているかを理解するという点を損益分岐点として（そのような点を越えることができる有能な設計者のみが）より速くて安全なプログラムを作れるようになるのだと思う。

またそのような有能な設計者なら、「そんなコストをかけるだけの将来が.NetとMSにあるのか？」「そのようなライブラリを自分で書く（書かせる）ほうがよほど身になる（部下・下請けが育つ）のでは？」という疑問を持つだろう。

パターン

上とはぜんぜん違う話。

パターンについて、各論文のおいしいところを拾ってまとめているMS社員の文書があったのでメモ。

リンク	備考
パターンを使用してソフトウェア ソリューションを定義する