上のを書いていて現状のやり方には行き詰ってしまった。
コンストラクタ内でコンパクションを起こしうる関数を絶対に使ってはいけないという制限はきつ過ぎる。
コンパクションを起こす可能性のある関数の代表はMC_knlAllocなどのメモリ割り当てだから、
そのままMC_knlAllocを使っていたら、メンバ変数にオブジェクトをnewするかもしれない
コンストラクタのようなものがコンパクション発生の可能性が一番高いのだ。
というわけで、実践はしていないが何とか方法を考えてみた。
以下の方法はまだ構想段階で試していないことには注意してほしい。
まず、コンストラクタ内でMC_knlAlloc系を陽にも陰にも呼ばない方法を考えてみる。
アプリの実行開始時に、アプリが使用するヒープ容量の限界分をMC_knlAllocで確保する。
次に、アプリ内でのメモリ割り当てでは、この領域からメモリを確保するようにする。
しかし、この場合でも最初に確保する巨大な領域自体が移動する可能性がある。
とすれば、アプリ側は全てのポインタをスマートポインタに変更して、
そのスマートポインタでは"メモリ領域の最初のアドレスを取得する為のハンドル"と"そこからのオフセット"を保持しなければいけない。
オブジェクトのアドレスを得る時は常にメモリ領域の先頭アドレスを取得し、そのあとオフセットを加算すればよい。
これでコンストラクタ内のアプリ側のメモリ割り当てにおけるコンパクションの可能性をゼロにできた。
あとはAPIの内部でメモリを割り当てる関数、副作用としてコンパクションを起こすと書かれているものが問題になる。
これらはコンストラクタの内部で呼んではいけないままだ。
しかし、それでも万が一コンパクションを起こす可能性がコンストラクタ呼び出しの中にまじった場合に備えて、
コンパクションの可能性を最小限にしたい場合、
タイマーハンドラの最初あたりで、残りメモリーの総容量ギリギリを指定してMC_knlAllocを呼び出して、
無理やりコンパクションを起こせば、可能性は最小限にできるかもしれない。
またこの時はMC_knlCallocは使わないほうがいいだろう。
コンパクションを起こさせる為のダミーの呼び出しなのにメモリをゼロクリアしていたら実行時間に問題が出るだろうから。
