OOPと自動メモリ管理

Simula はサブルーチンの不自由さに対し改善を施すことで、クラスとオブジェクトを発明しました。その副作用として、コールスタックによる自動メモリ管理が使えなく(←「コイツ使えね~っ」の「使えない」）なってしまいました。

* * *

「階層的プログラミング構造」Ole-Johan Dahl, C.A.R Hoare より引用しつつ。

Simula がシミュレーションのための言語を模索する過程でクラス・オブジェクトの発明に行きいきさつは、

平行しているプロセスを表現するために, 対応するプログラム要素が,計算機で多重プログラム(multiprogram)処理されなければならない,というわけではない.しかし,プログラムは,一時的に停止(中断)し,後で止まっていたところから再び実行出来ることが必要である.そこで動作している対象,すなわちシミュレーションにおける“プロセス”は,スケジュール機構 (時間割り当ての機構,scheduling mechanism) の制御のもとで,擬似的に平行して(in pseudo-parallel)働く (半) コルティンによって表現されるであろう.

がしたいので、ブロック（サブルーチン）といったものに、

新しいブロックの実例を作り出すプログラムでは,制御が戻ってきたときにには,その実例は消滅しているので,“もの”を持って存在している対象として,それと相互に作用し合うことは決してできないという欠点がある.（中略）つまり,ブロックの演算的な側面が強調されすぎているのである.
SIMULA 67 では, ブロックの実例はそれを呼ぶ出す文より長い間存在することが出来るし,プログラムでそれを参照する必要のある限り存在し続けることが出来る.

という改良を施しちゃった。コレがクラスとオブジェクトの始まり。

でも、ブロック（サブルーチン）間の構造が、コール/リターン (↓）じゃなくなっちゃったから、

最近に起動されたブロックの実例が最初に消滅するという意味で,ブロックの実例の存在が入れ子構造をなす事を保証するように留意して言語の規則が設計されている.このことによって, ALGOL 60 の処理系では, 動的に記憶場所を割り当てて解放する方法としてスタック(stack)を用いることが出来る

コールスタックによるいかした自動メモリ管理もつかえなっちゃった。

だから自動メモリ管理の主役は、コールスタックからガベージコレクタに移ったのです。そんなわけで Simula な本を読むと、OOP とガベージコレクタは切っても切れない中だと思えてしまう。

そう、

SIMULA では,コルティンは,クラスの1つの対象で表される.

と、こんな感じ。（注：「対象」とかいて「インスタンス」と読む）

* * *

さて、そういう Simula な OOP なるものに対して、「コールスタックで頑張ろう！」「手動メモリ管理だって、むしろ本物のプログラマには実用的だ」と改善をほどこした C++ とスッポスッポせんせは凄いと思います。ここは痺れて憧れる所。

C++ の面白い点はまさにそこで、だからコールスタックなメモリ管理が実行されるタイミングにフックが仕掛けられるようになっていて、そこら辺をプログラマの意志でカスタマイズできてしまう。それがテンプレートと共にメタプログラミングの土壌になるのですが、――って、話がそれちゃった。

なので、C++ はガンキャノンからキャノンを取ってしまったくらい、ものすごい変わり種のOOPLだと思うのだけれども、そういう認識じゃなくって「代表的なOOPLの一つ」として敷衍してしまったのは、本当に不幸なことだとも思います。

――なぁんてことをだらだら書いてしまったのは、先日新人の子に「C ではガベージコレクタがないので、昔のプログラマは全部手動でメモリ管理してたのですね！超人ですね！」みたいな事をいわれてギョッとしたからです。いあいあ、Cプログラマだってやたらめったら malloc してるわけじゃありませんから。

Cの構造化部品は関数だからコールスタックがうまくいくので、Cプログラマは 9割方(もっと?)自動メモリ管理のお世話になりながらプログラミングしています。でもC++は新しい構造化部品は導入したけれどそれ用の自動メモリ管理機構は導入しなかった。だからメモリ管理の道具がCと同じコールスタック + 手動ヒープ管理であっても、同じような楽さ/大変さだと考えてはいけないっていうのがミソで、 C++ のような殆ど手動のメモリ管理な世界は、Cなプログラマからみても超人的な所行です。

蛇足

なんか思い出しました。