私は、特定の型のオブジェクトを一揃え持っています。それぞれの型は、同じ型の他のオブジェクトを保持するために両端キューを割り当てることができます。私は両方の端で高速アクセスが必要なので、特定のオブジェクトはおそらく他の多くのオブジェクトを参照する可能性があるため、両端キューを使用しています。多数のアイテムでは両端キューがありますが、小さなメモリではメモリ使用量は少ないですか？
しかし、オブジェクトの多くまたはほとんどが他のオブジェクトをほとんど参照していない可能性があります。この場合、両端キューのメモリ使用量はかなり大きいです。私が使用している実装は、最初のpush_back（）を実行するとすぐに、ショットで4096バイトを割り当てています。両端キューの各要素はわずか8バイトです。それは、特に私がこれらのオブジェクトの多くを作っているため、無駄なスペースがたくさんあります。
私が言ったように、ほとんどのオブジェクトが他のオブジェクトをほとんど参照していないにもかかわらず、特定のオブジェクトが実際に他の多くのオブジェクトを参照できるため、かなり複雑なものが必要です。
私の最初の考えは、dequeを自分自身で成長させるためにcapacity（）とreserve（）を使用していましたが、私のコンパイラはそのような関数がdequeにないことを通知しました。
私はおそらく、デキューのようなインターフェイスを持つクラスを作成することを考えていました。これは、ベクタとデキューであり、ベクタは（たとえば）16個の要素が存在するまで使用され、その後ベクトルは破棄されます。デュークはそこから使用されます。
ベクトルは要素数が少ない場合にのみ使用されるため、push_front（）とpop_front（）は速度面で非効率的になりすぎることはあまりありません。 capacity（）とreserve（）を使ってベクトルを制御すると、より多くの要素が存在するときにdequeが多くのメモリを使用することはあまり重要ではありません。
しかし、このような自分のクラスをローリングする前に、このようなものが既に存在するかどうかを確認したいと考えました。また、なぜ誰かが何らかの理由で私がこのようなことが悪い考えであると思っていない、または誰かが何か関連する提案があると思っていないなら、それを聞いて欲しいです。
ありがとうございます。
実際、 'std :: deque'は要素を1つの大きなブロックに格納しないので、' capacity（） 'または' reserve（） 'を持ちません。 –
@トマラク：それはしたかったと思うが、どうしてそうすべきではないのか分からない。この理由ではなく、単にスペースを確保できれば、次の数回の挿入でメモリ割り当ての失敗を防ぐことができます。もちろん、値型の非割り付けコピーコンストラクタを仮定します。しかし、他のすべての標準コレクションにも同じことが当てはまります。異なるコンテナの場合、それがどのように実装されるのかを見るのが難しくなります。だから私は線が 'ベクトル'で描かれたと思います。 –
@SteveJessop：そうです、どういう根拠がTBHなのかよくわかりません。私はそれが 'std :: deque'がそのメモリチャンクを使ってはるかに「賢い」ため、コンテナーにすべてのことをさせることにしたのではないかと推測します。 。 –