FIFOにはどのSTLコンテナを使用すればよいですか？

どのSTLコンテナが私のニーズに最適ですか？私は基本的に10要素幅のコンテナーを使用しており、最も古い要素（約100万回）を継続しpush_backながら新しい要素を継続的に追加していますpop_front。

私は現在std::deque、タスクにa を使用していますが、std::listそれ自体を再割り当てする必要がないので（またはa std::dequeをaと間違えているので）、aの方が効率的かどうか疑問に思っていましたstd::vector。または、私のニーズにさらに効率的なコンテナはありますか？

PSランダムアクセスは必要ありません

無数の答えがあるので、混乱するかもしれませんが、要約すると：

を使用しstd::queueます。これの理由は簡単です：それはFIFO構造です。FIFOが必要な場合は、std::queue。

それはあなたの意図を他の誰にも、そしてあなた自身にも明らかにします。A std::listまたはstd::dequeしません。リストは、FIFO構造では想定されていない場所に挿入および削除dequeできます。また、FIFO構造では実行できない、両端から追加および削除できます。

このため、を使用する必要がありqueueます。

今、あなたはパフォーマンスについて尋ねました。まず、この重要な経験則を常に覚えておいてください：最初に良いコード、最後にパフォーマンス。

これの理由は単純です。清潔さと優雅さの前にパフォーマンスを追求する人は、ほとんどの場合最後に終了します。彼らは本当に何もないようにするために良いことをすべて放棄しているので、彼らのコードはドロドロになります。

最初に適切で読みやすいコードを書くことで、パフォーマンスの問題のほとんどは自動的に解決されます。そして、後でパフォーマンスが不足していることがわかった場合は、プロファイラーをきれいなコードに追加して、問題がどこにあるかを簡単に見つけることができます。

とstd::queueはいえ、アダプターにすぎません。安全なインターフェースを提供しますが、内部では別のコンテナーを使用します。この基礎となるコンテナーを選択できます。これにより、かなりの柔軟性が得られます。

それで、どの基本的なコンテナを使うべきですか？我々はことを知っているstd::listとstd::dequeの両方が必要な機能を提供（push_back()、pop_front()、およびfront()）、私たちはどのように決めるのですか？

まず、メモリの割り当て（および割り当て解除）は、OSに行って何かをするように要求することを伴うため、一般的に、迅速に行うことではないことを理解してください。A listは、何かが追加されるたびにメモリを割り当て、それがなくなったら割り当てを解除する必要があります。

Aはdeque、他の一方で、チャンクで割り振ります。割り当て頻度が低くなりlistます。リストと考えてください。ただし、各メモリチャンクは複数のノードを保持できます。（もちろん、実際にどのように機能するかを学ぶことをお勧めします。）

したがって、それだけでdequeは、メモリを頻繁に処理しないため、aの方がパフォーマンスが向上します。一定サイズのデータ​​を処理しているという事実と混じり合って、おそらくデータの最初のパスの後で割り当てを行う必要はありませんが、リストは常に割り当てと割り当て解除を行います。

理解する必要がある2番目の事項は、キャッシュのパフォーマンスです。RAMへのアクセスは遅いため、CPUが本当に必要な場合は、メモリのチャンクをキャッシュに戻すことで、この時間を最大限に活用します。dequeはメモリチャンクに割り当てられるため、このコンテナ内の要素にアクセスすると、CPUが残りのコンテナも戻す可能性があります。これでdeque、データがキャッシュにあるため、への以降のアクセスはすべて高速になります。

これは、データが一度に1つずつ割り当てられるリストとは異なります。これは、データがメモリ内のあらゆる場所に分散する可能性があり、キャッシュのパフォーマンスが低下することを意味します。

したがって、それを考慮すると、a dequeの方が適しています。これが、を使用する場合のデフォルトのコンテナである理由ですqueue。とは言っても、これはまだ（非常に）教育を受けた推測にすぎません。あるコードdequeとlist他のテストを使用して、このコードをプロファイリングし、確実に知る必要があります。

しかし、覚えておいてください。コードをクリーンなインターフェースで動作させてから、パフォーマンスについて心配してください。

ジョンは、listまたはをラップするdequeとパフォーマンスが低下するという懸念を提起します。もう一度言いますが、彼も私も自分でプロファイリングせずに確実に言うことはできませんが、コンパイラが行う呼び出しをインライン化する可能性がありqueueます。つまり、と言うとqueue.push()、実際にはとだけ言っqueue.container.push_back()て、関数呼び出しを完全にスキップします。

繰り返しになりますが、これはqueue経験に基づく推測にすぎませんが、基になるコンテナーrawを使用する場合と比較すると、a を使用してもパフォーマンスは低下しません。前に言ったように、を使用してくださいqueue。これは、クリーンで使いやすく、安全であり、本当に問題のあるプロファイルとテストになる場合に使用します。

チェックしてくださいstd::queue。基礎となるコンテナタイプをラップしますstd::deque。デフォルトのコンテナはです。

パフォーマンスが本当に重要な場合は、Boost循環バッファーライブラリを確認してください。

最も古い要素（約100万回）を使用しpush_backながらpop_front、新しい要素を継続的に使用しています。

コンピューティングでは、100万人は本当に大きな数ではありません。他の人が示唆したstd::queueように、最初のソリューションとしてa を使用します。遅いと思われる場合は、プロファイラーを使用してボトルネックを特定し（推測しないでください）、同じインターフェースを持つ別のコンテナーを使用して再実装します。

なんでstd::queue？それが持っているすべてがあるpush_backとpop_front。

キューは、おそらくよりも単純なインタフェースである両端キューが、そのような小さなリストについては、パフォーマンスの違いは、おそらくごくわずかです。

リストについても同様です。必要なAPIの選択次第です。

を使用しますstd::queueが、2つの標準Containerクラスのパフォーマンスのトレードオフに注意してください。

デフォルトでstd::queueは、は上のアダプタですstd::deque。通常、これは、おそらく一般的なケースである、多数のエントリを含む少数のキューがある場合に良好なパフォーマンスを提供します。

ただし、std :: dequeの実装に目を向けないでください。具体的には：

"... dequeは通常、最小のメモリコストが大きくなります。1つの要素のみを保持するdequeは、完全な内部配列を割り当てる必要があります（たとえば、64ビットlibstdc ++のオブジェクトサイズの8倍、オブジェクトサイズの16倍、または4096バイトのいずれか大きい方） 、64ビットlibc ++の場合）。」

それを排除するために、キューエントリがキューに入れたいもの、つまりサイズがかなり小さいと仮定すると、4つのキューがあり、それぞれに30,000のエントリが含まれている場合、std::deque実装は選択肢となります。逆に、それぞれが4つのエントリを含む30,000のキューがある場合、そのシナリオでstd::listはstd::dequeオーバーヘッドを償却しないため、実装はおそらく最適です。

キャッシュがどのように重要であるか、Stroustrupがリンクされたリストをどのように嫌うかなど、多くの意見を読むでしょう、そしてそれらのすべては特定の条件下で本当です。盲目的にそれを受け入れないでください。そこにある2番目のシナリオでは、デフォルトのstd::deque実装が実行される可能性はほとんどないからです。使用状況を評価して測定します。

このケースは非常に単純なので、独自に作成できます。これは、STLの使用がスペースを取りすぎるマイクロコントローラーの状況でうまく機能するものです。割り込みハンドラからメインループにデータと信号を渡すのに最適な方法です。

// FIFO with circular buffer
#define fifo_size 4

class Fifo {
  uint8_t buff[fifo_size];
  int writePtr = 0;
  int readPtr = 0;
  
public:  
  void put(uint8_t val) {
    buff[writePtr%fifo_size] = val;
    writePtr++;
  }
  uint8_t get() {
    uint8_t val = NULL;
    if(readPtr < writePtr) {
      val = buff[readPtr%fifo_size];
      readPtr++;
      
      // reset pointers to avoid overflow
      if(readPtr > fifo_size) {
        writePtr = writePtr%fifo_size;
        readPtr = readPtr%fifo_size;
      }
    }
    return val;
  }
  int count() { return (writePtr - readPtr);}
};