ハンドルベースのリソースマネージャに対する考察 part3

Program ProgramIdiom 備忘録

前回の続き（http://d.hatena.ne.jp/studiokingyo/20060716）


さて、前回の「続く･･･」を見たところで生粋のシーゲンガーならば身近なリソースマネージャー(以下RM)の正体は気付いていると思う。
そう！実はmalloc()だったのである。
mallocこそ最高のリソースマネージャであった。
メリットとしては

  • C言語標準の機能なので面倒なプログラムを組まなくて良い
  • 様々な形でエラーチェックなどを行ってくれるラッパーがある（VCの場合はcrtdbg.h）
  • 元々C言語標準のライブラリで昔からその手のアルゴリズムや構造の成果物が存在している

デメリットとしては

  • free()を忘れるとメモリリークする
  • malloc() free()の実装がダメだと処理速度が遅くなる
  • malloc() free()の呼び出しすぎは処理速度低下の原因になる(といっても、今のPCではそんなの屁でもない事が多いが･･･）

とまぁ、必要なメモリ領域を取得して開放するという基本的なRMの概念において非常に良く出来た機構だったのだ。
リソースのIDの変わりにポインタを使っているというところがミソだ。
C言語にとってのリソースIDは実はポインタによって達成されていたのだ。
そしてRMはmalloc() free()によって達成されていたのだ。
これに気付いた時は「今まで何を考えていたんだろう*1」と後悔した。
ソフトウェアを作る事に勤しむ場合は私のように根本的なアルゴリズムを考えると貴重な学生としての人生を無駄にすると断言しても良い。


今の時代、成果物を生成するには素直に.NETでもC#でも使って一思いにバサッとコーディングしまくってある程度動くものを作ったほうがなにかと成果物を生成しやすいと感じてしまった次第だ。
後からリファクタリングすればある程度ライブラリ化は出来ると思っている。*2


さて、
http://mkosaki.blog46.fc2.com/blog-entry-241.html
を参考にしてNYSLのmalloc()の実装でも作りますかね。（やっぱりソフトウェア作る気 Nothing...！？）


次回は私なりに考えてみた別の方法でのRM機構について少しづつ紹介していこうと思う。
続く･･･

*1:http://d.hatena.ne.jp/studiokingyo/20040822

*2:実際にこのような方法を行った事は無いので自分なりには納得はいかないが･･･私の第六感がそういっているのだ。