前回言っていたプールを実現するためには、配列のようなものがいる。
まあ、リストである。

リストのアルゴリズムは知っていたが、組んだことはほとんどなかったので、うんうん言ってランタイムエラーやらバグを吐きながら
実装しておりました。

が、C++にはSTLなるものがあり、STLの中には、listというものもあるそうな。

おお、list便利。ついでにtemplateも使って、何だかC++プログラマっぽくなりつつあります。

さらに、任意の場所にあるリストとかも消せるようにしようとか思ったら、今度はイテレータとやらが登場。
おお、これまた便利。なんということでしょう。

STLはきっと難しい。自分にはまだ早い。なんて思っていましたが、こんな便利なものがあっていいものかとびっくりしました。
C++の世界はとても広いです。

もっともっと、言語だけでも学ぶことがあるのだと、一人意気込んでいる私です。

オブジェクトマネージャーを作るならリストを使うのはやめたほうが良いです。
「何番目のオブジェクトを利用するのか」というハンドル番号だけを利用者に渡し
利用者はそのハンドル番号からしか関連付けされているオブジェクトの情報を取得したりできない、させないようにするのがマネージャーの主な仕事ですが、
これはつまり、「いつ利用者が何番目のデータを参照するのか」が不特定ということにもなります。
リストはインデックスを持たないのでランダムアクセスに弱く配列とは使いかってが違いますし、そもそもオブジェクトマネージャーが配列の動的確保なんてする必要性はあまりないです。

普通に最初から最大数を定義して固定長の配列を作ってアクセスしたほうがパフォーマンス的にも実装的にも速いと思いますよ

そういうものなのですか・・・我ながらいい手だと思いましたが、難しいものです・・・。

調べてみると、双方向リストはランダムアクセスに弱いのですね。知りませんでした。
せんちゃさんの言っている方法で再度考え直してみます。度々アドバイスしてくださり助かります。

ありがとうございました。

双方向リストの扱いどころとしては３Dモデルの描画などに使うといいと思います。
メッシュは可変な階層構造を持つので連結リストが必要になります。

３Dモデルの描画などだとlistで持った各ノードを再帰的に呼び出す関数を作ってノード別に描画する
というのが一般的な方法でしょうか

プールに使えないのは双方向リストが悪いのではなくて、STLというか汎用コンテナの実装のせいです。
汎用コンテナは参照するオブジェクトの外部にコンテナを作るので、コンテナの操作は外部から行う必要があります。

オブジェクト自身が双方向リストのノードとなる実装にするとポインタをそのままハンドルとして使って走査が不要になりますしリストに関する操作をオブジェクト内部で完結させることも可能になります。
ウチのブログで公開してるタスクリストがそういう実装になってます。

>せんちゃさん

3Dモデルの描画でlistですか・・・
いまだにDrawSubSetに頼っている状態なので、ピンとはきませんでした。
しかし重要ではあるようなので、覚えておきます。ありがとうございました。

>ISLe

コンテナというのですね。確かに、描画するときにわざわざコンテナから取り出して描画していました。
こういうものなのだと思っていましたが、コンテナに頼らずに描画できるよう頑張りたいと思います。
ありがとうございました。