exket は C++ & MFC で書いてます。当然ガーベジコレクションとは無縁です。
仕事で使う言語は今のところ C++が圧倒的に多いですが、たまに（というか今^^;..）Javaとかで組んでいると、このオブジェクトはいつ破棄されるんだろう・・ とかすごく気になってしまうｗ
今はもうGUIが大部分を占めるようなちょろっとしたものならわざわざC++で苦労してメモリ管理しながら組むよりは、C#で作ったほうがよっぽど生産的という世の中。
これから、64bit当たり前、メモリも今の10倍100倍当たり前の世の中になったら、GC任せで気兼ねなく作れる範囲がもっと増えていくんでしょう。
ただ、今はまだ、GC任せでは心許ないマシンがまだまだ大多数に思える。
メモリ1GBのXPマシンみたいな、メモリの大部分をシステムに喰われてしまう構成のマシンは現在たくさんあるし、数年くらいはまだ主流を占めるでしょう。
exketなんかは現在メモリ70MBくらい消費してて、どんなに増えても100MB以内には収めたい。
メモリが潤沢でないマシンを基準に考えるとそれが限度。（これでも公式ブラウザの数倍もメモリを使うとても贅沢仕様ｗ）
そうなると、４万のサークルのサークルカットを表示するのに、不要になったサークルカットを放ったらかしてGC任せというのはちょっと厳しいという印象。
C#でかかれてるし～ぽんさんはREADMEには70～80MBと書かれてますが、普通に使ってると120MBは超えて、UWXGAクラスの画面でどばーっとスクロールすると瞬間最大で300MBくらい行くことがあります。メモリ1GBのXPでし～ぽんを暫く使ってると、ページスワップが頻発するのかWinや他のアプリの動作がしばらくもたついてしまうんだが私の環境だけだろうか。
ただまあ、あと５年もしないうちにこれくらい何の心配もなくGC任せでいける世の中になるんでしょう。っていうかなって欲しい。楽したいです^^;..
自分でメモリ管理する時に面倒なのは、マルチスレッド化した時。
exketで、読み込みが間に合わないくらいの高速スクロールをやると、裏のスレッドでサークルカットを読み込み終わって表示しようとしたらそのサークルは既にスクロールアウトしていた、みたいなことになっていて、じゃあそのサークルカットはいつ、誰（どのスレッド）が破棄するのか、ってのがとても面倒なことになる。
で、これについては、Objective-C というか NextStep流の Retain&Release の参照カウンタ方式で管理して、Release時にカウンタが０になったらそこで破棄みたいなカンジでやってます。こういうものについては GCで楽してーなぁ・・・ と思います。^^;..
そういえばObjective-Cも2.0でガベコレ搭載しましたね。
以前 Javaで書かれたシミュレーションプログラムの手直しの仕事をしたのだが、２次元座標を保持するのに
public class Point{ public int x; public int y; }
みたいなクラスを使っていて、これがシミュレーション中に数百万個はゆうに作られてはガンガンGC行きになっていて、これをヤメて単純に int x; int y;で持つようにしたらそれだけで実行速度が格段に速くなった。
ただその代償として、ベクトル演算なんかは全部ベタに展開して書かなければならず、コード量は増え、可読性はガッツり減った。
学校で研究目的ってんならJavaで可読性を優先すべきだし、この手のメモリがいくらあってもありすぎることはない計算でスピードやメモリ量優先っていうんなら C++ でしっかりメモリ管理しながら書くべきだよなあ。
そういう用途でも気兼ねなくガベコレ使える世の中はいつになったら来るだろうか。
早く来てください。
