・・・ということで、VAはあちこちに分散させても管理がうまくいかなくなるだけなので、どこか一ヶ所で管理すべきだと考えました。vaTable[]みたいなのを作って、そこにVA型のオブジェクトを置くわけです。vaTable[]が移動したらどうしましょう。移動させないという解もありなのですが、ここは移動も想定して(その代わりvaTable[]は分散せずに一ヶ所にまとめる)、vaTable[]の要素へのポインタを持つのはやめて、vaTable[]の何番目の要素なのかを持つことにします。この新しいルールでは、ポインタは2つの整数の組で表現されるのです。vaTable[]の何番目なのか、そしてその配列の何番目なのか。結これはOSASKでやっていたslot番号の仕組みにかなり似ています。あの時slotは固定長でしたが、vaTableは可変長です(だから移動もありうる)。この方式では、VA型のオブジェクトはポインタ型の変数を持っているのでCPUのアドレスサイズに依存しますが、アプリ側のポインタは整数を2つ持っているだけなので、「アプリ全体でポインタをいくつ扱うのか&配列の要素数の上限」だけで必要なintのビット数が決まり、CPUに依存しなくなります。移植性も向上するのです。いうことで、これからslotライブラリを作ります。それにしても、整数2つでポインタを表現するって、まさにセグメンテーションですよねー。ちなみにこの方式ではアプリは生のポインタを長期には保存しないので(ループの中で配列長を変更しない間に一時的に持つとかは十分ありうるし、そうしないとスピードが出ない)、それを利用して、オブジェクトの再配置などを行うことができる。メモリのデフラグみたいなもの。・・・その間はアプリを止めておかなければいけないかもしれないけど、それをもって一概にダメだということはできない。従来の方式では、アプリを止めても再配置などできなかったのだから。選択肢が増えただけ、ずっとマシである。