3

私の STL コンテナのメモリ使用量は変動しやすいと予測されています。つまり、頻繁に縮小したり拡大したりします。STLコンテナの型宣言にアロケータを指定することで、これを説明しようと考えています。プール アロケーターがこの種の状況に対処するためのものであることは理解していますが、私の懸念は、ボラティリティがプールが説明する以上のものになることです。それを克服するには、適切なプール メトリックを決定するために多くのテストを行う必要があります。

私の理想的なアロケーターは暗黙のうちに memoryを解放することはありません。実際、アロケーターが破棄されたときにのみメモリが解放される場合は、完全に受け入れられます。未使用のメモリを明示的に解放するメンバー関数は便利ですが、必須ではありません。私が言及しているのは、オブジェクトごとのアロケーターのように聞こえ、これは標準に違反していることを知っています。標準に固執したいのですが、その中でこれを解決できない場合は放棄します。

私は初期のパフォーマンスにはあまり関心がなく、平均的なパフォーマンスに関心があります。別の言い方をすれば、一度に単一の要素またはそれらのプールが割り当てられるかどうかは問題ではなく、その割り当てが new/malloc の呼び出しになるかどうかは重要です。私は自分のアロケータを書くことに問題はありませんが、これを達成する既存のアロケータを知っている人はいますか? それが違いを生む場合、これは連続したメモリ コンテナー (vector、deque など) の場合になりますが、一般化されたソリューションが適しています。

4

1 に答える 1

1

これが基本的すぎないことを願っています。

メモリは、アイテムを削除するよりもアイテムを追加するために割り当てられ、解放されます

アプリケーションで許可されている要素の最大数を知っていない限り、メモリを「解放」することは不可能だと思います。CRT はより大きなメモリ ブロックを適切に割り当てようとするかもしれませんが、失敗した場合はどのように処理しますか?

説明:

動的に拡張するベクトルを作成するには、ほとんどの push_backs を処理するためのより大きな容量と、これが不十分な場合に処理するための再割り当てがあります。

  • 再割り当て中に、新しい大きなメモリ部分が「新しく」作成され、古いメモリ部分の要素が新しいメモリ部分にコピーされます。
  • 要素を push_back する間、イテレータを保持しないことが重要です。これは、再割り当てによって
    、イテレータが指すメモリ位置が無効になるためです。

  • C++11 と TR1 では、要素へのポインターのみをコピーする必要がある完全な転送が行われる場合があります。これは、コピー コンストラクターの代わりにムーブ コンストラクターを介して行われます。

ただし、再配分は極力避けたいようですね。

vector のデフォルト アロケータを使用して、初期容量を指定できます。

  • 容量は割り当てられたメモリで、サイズは要素の数です。

  • メモリは、構築時およびサイズが容量に達した場合にのみ割り当てられます。これは push_back(); でのみ発生します。

  • デフォルトのアロケーターは、容量を倍数 (1.5、2.0 など) ずつ増やして、再割り当てが線形時間で行われるようにします。したがって、データをプッシュバックするループがある場合、それは線形です。または、事前に要素の数がわかっている場合は、一度に割り当てることができます。

探索できるプールの概念があります。プールのアイデアは、要素を破壊するのではなく、非アクティブ化することです。

それでも独自のアロケーターを作成したい場合、これは良い記事です。

カスタム アロケーター

于 2011-10-10T21:11:09.090 に答える