2

次の要件を満たすために、新しいプロジェクトに適切なデータ型を選択しようとしています。

  • ハイ！タイムクリティカル（データ入力用）
  • コンテナー内のデータに対するランダムな挿入や操作はありません (読み取り専用で順次挿入)
  • サイズはコンパイル時に固定されます（動的割り当ては不要です）
  • データは、(スレッドまたはサービスによって) 定義された期間が経過すると順次削除され、空のスペースは新しく来るデータ用に再び使用できる必要があります。

元。コンテナに 1,2,3,4,5,6 が挿入されたとしましょう。しばらくすると、6 が削除され、7 が挿入されるため、リストは 7,1,2,3,4,5 になり、次に 5 が削除されます...ただし、サイズは同じでなければなりません。

パフォーマンスとメモリの観点から、どのデータ構造が最も効率的で、私の状況に適しているのか疑問に思っていました。

ありがとう...

編集:ちなみに、基本的な FIFO ロジックとは少し異なります。10 要素 (サイズ) のデータ コンテナーを作成し、コンテナーの最後 (サイズの制限) に達していなくても 3 つの要素しか挿入しなかったとします。指定した時間が経過すると削除されます。

ところで、boost:array を使おうと思っていたのですが、std:vector と std:deque について少し混乱しました。この状況で何か特別な利点はありますか?

4

5 に答える 5

1

おそらくFIFOをサポートする最適化された固定サイズのコンテナによってバックアップされるqueueが必要なようです。

于 2013-11-05T09:14:16.597 に答える
0

std::vector に裏打ちされた std::queue が必要であり、一定の容量があります。

std::vector<YourType> underlying_storage(capacity);
std::queue<YourType, std::vector<YourType>> queue(std::move(underlying_storage));

// Now your queue is backed up by vector with predefined capacity
于 2013-11-05T09:48:39.980 に答える
0

データ構造とアルゴリズム クラスから、挿入と削除が行われる可能性が高い場所では、何らかのリンク リストを使用する必要があることがわかっています。しかし、私たちが知っていることは間違っているかもしれません。

現代のメモリは、膨大な量のデータを猛烈な速さでコピーし (そのため、データのコピーについて考えるほど心配する必要はありません)、線形検索にキャッシュを使用します (これは、リンクされたリスト構造が効果的に打ち負かします)。これら 2 つの要因を組み合わせると、古き良きベクターまたは boost::array を使用する必要があることを意味する場合があります。

しかし、私の言葉を鵜呑みにしないでください。Bjarn Stroustrup がすべてを説明しています。

于 2013-11-05T09:42:27.527 に答える