問題タブ [circular-buffer]

この質問を確認しましたが、探しているものではありません。

ログ ファイルのサイズ (たとえば、10MB) を制限する方法を見つけようとしています。

• 追加するのではなく、最初から書き始めるか、または
• 追加し続けますが、そうするにつれて内容を最初から削除します

言語はあまり気にしないでください - 可能な限り:)

注: ローリング ログ ファイル アプローチ (目標サイズに達し、名前を変更し、ログを継続する) を認識しています。私はそのようなロールを避けようとしています。

これは、この質問のフォローアップです。以前に受信したUART値を表示します。

マイクロコントローラに循環バッファを実装した後、ポインタに問題があるようです。

RS-232で送信：ADE1234
受信（バッファ= 8）：E24AE2 / E2AE24（2つの間を反転）受信（バッファ= 16）：D234E1（Aはシンクロバイトであるためスキップされます）
受信（RX_BufSize = 32）：DE1223 / DEE123 / DE1234 / DE12E1（ランダムに反転）
期待される受信：DE1234

初期化

LCDに表示されるデバッグ値

受信割り込み

ソースからの関数

Detect_Cmd_RXDは、1/256秒ごとに呼び出されます。その間、UART受信バッファで少なくとも7つの値が送信されます。

書き込みプロセスが非常に高速で、読み取りポインターに追いつく可能性はありますか？Detect_Cmd_RXDをより頻繁に呼び出す以外に、この問題を解決するにはどうすればよいですか？

私はHaskellで循環バッファを必要とする小さなコンセプトプロジェクトに取り組んでいます。O（1）回転の配列を使用してバッファーを作成できましたが、もちろん挿入/削除にはO（N）が必要です。挿入と削除にO（1）がかかるように見えるリストを使用する実装を見つけましたが、左右のリストを維持するため、回転時に特定の境界を越えるとO（N）時間がかかります。命令型言語では、O（1）の挿入、削除、およびローテーションを使用して、二重にリンクされた循環バッファーを実装できます。Haskellのような純粋な関数型言語ではこれは不可能だと思いますが、私が間違っているかどうか知りたいです。

VB.NET のヒープに循環バッファを作成するにはどうすればよいですか?

これは、ソフトウェア シンセの開発をサポートするために、winmm.dll waveoutopen および waveoutwrite への P/Invoke を介したオーディオ再生に使用されます。

現在、マーシャル クラスを使用して、ヒープ内に通常のバイト配列を構築しています。

circular_bufferBoostライブラリと Interprocess ライブラリを使用して、共有メモリに循環バッファを作成しようとしています。問題なく共有メモリにベクトルを作成するために、インタープロセスのドキュメントに記載されている例をコンパイルして実行しました。ただし、Boost circle_buffer を次のように使用するように変更すると、次のようになります。

コンパイル エラーが発生します (原因:) segment.construct()。私が間違っていることは何ですか？circular_bufferにリストされているコンテナの 1 つでないため/boost/interprocess/containers、つまり、Interprocess と互換性がないためですか?

ありがとう、

ハ

閉じた (円形) のように動作するカスタマイズされた ListView (または同様の) を作成したい:

1. 下にスクロール - 最後のアイテムに到達した後、最初のアイテムが始まります (.., n-1, n, 1, 2, ..)
2. 上にスクロール - 最初のアイテムに到達した後、最後のアイテムが始まります (.., 2, 1, n, n-1, ..)

概念的には単純に思えますが、明らかに、これを行うための直接的なアプローチはありません。誰でも正しい解決策を教えてもらえますか? ありがとうございました ！

私はすでに回答を受け取っています (Android-Developers google groups の Streets Of Boston から) が、なんとなく醜いように聞こえます :) -

これを行うには、独自のリスト アダプター (BaseAdapter からサブクラス化) を作成しました。

getCount() メソッドが HUUUUGE 数を返すように、独自のリスト アダプターをコーディングしました。

また、アイテム「x」が選択されている場合、このアイテムはアダプタ位置='adapter.getCount()/2+x'に対応します

アダプターのメソッド getItem(int position) については、アダプターをバックアップする配列を調べて、インデックスの項目をフェッチします: (position-getCount()/2) % myDataItems.length

すべてを正しく機能させるには、さらに「特別な」ことを行う必要がありますが、アイデアは得られます。

原則として、リストの最後または最初に到達することは依然として可能ですが、getCount() を約 100 万程度に設定すると、これは困難になります :-)

私はこれについて特に密集していますが、私がやりたいことは共通でなければならないので、重要で基本的なポイントか何かが欠けているようです:

マネージャー プロセス ( ) から固定サイズのリング バッファー オブジェクトを作成する必要がありますProcess M。このオブジェクトには、バッファから読み書きするメソッドがwrite()あります。read()読み取り/書き込みメソッドは、独立したプロセス (Process RおよびW)によって呼び出されます。

バッファを実装しました。これはSharedBuffer<T&>、boost::interprocess を使用して SHM にバッファ スロットを割り当て、単一のプロセス内で完全に動作します。SO でこの質問とその質問への回答を読み、自分自身に尋ねましたが、異なるプロセスが共通のオブジェクトからメソッドにアクセスする方法についてはまだわかりません。Boost doc には、 SHM でベクトルを作成する例があり、これは私が望むものと非常に似ていますが、独自のクラスをインスタンス化したいと考えています。

私の現在のオプションは次のとおりです。

1. newCharles B. が私の質問に提案したように、配置を使用してください。ただし、彼は、POD 以外のオブジェクトを SHM に入れるのは得策ではないと警告しています。しかし、私のクラスには読み取り/書き込みメソッドが必要です。どうすればそれらを処理できますか?
2. クラス定義にアロケータを追加します。たとえば、ブーストで指定されたベクトルの例SharedBuffer<T&, Alloc>と同様に進めます。これは本当に複雑に聞こえます。
3. POD クラスに変更SharedBufferします。つまり、すべてのメソッドを取り除きます。しかし、プロセス間で読み取りと書き込みを同期するにはどうすればよいでしょうか。

私は何が欠けていますか？固定長のリング バッファは非常に一般的であるため、この問題には解決策があるか、何か間違ったことをしている可能性があります。

循環バッファの用途にはどのようなものがありますか？

循環バッファを使用する利点は何ですか？

二重リンクリストの代わりになりますか？

複雑さ以下の循環ソート配列内の特定の要素を検索したいと考えていますO(log n)。
例: を検索13し{5,9,13,1,3}ます。

私の考えは、循環配列を通常の並べ替えられた配列に変換し、結果の配列でバイナリ検索を行うことでしたが、私の問題は、私が思いついたアルゴリズムがO(n)最悪の場合にかかる愚かなことでした:

次に、i 番目の要素の対応するインデックスは、次の関係から決定されます。

私の変換 (循環から通常への) アルゴリズムが O(n) かかる可能性があることは明らかなので、より良いものが必要です。

ire_and_curses のアイデアによると、Java での解決策は次のとおりです。

うまくいけば、これはうまくいくでしょう。

C で循環バッファーを実装しようとしていますが、ウィキペディアでこの例に出くわしました (2014 年 7 月に削除されました)。バッファの最後から最初にラップアラウンドする読み取りが自動的に処理されるため、バッファから読み取る人にとって本当に素晴らしいインターフェイスを提供するように見えます。したがって、すべての読み取りは連続しています。

ただし、メモリマッピングや仮想メモリの経験があまりなく、それが何をしているのかを完全に理解しているかどうかわからないため、すぐに使用できるかどうかは少しわかりません。

私が理解していると思うのは、共有メモリファイルをバッファのサイズでメモリに2回マッピングしていることです。次に、データがバッファに書き込まれるたびに、メモリ内の 2 つの場所に一度に表示されます。これにより、すべての読み取りを連続させることができます。

本当に素晴らしいのは、POSIX メモリ マッピングの経験が豊富な人がコードをざっと見て、使用されている基本的なメカニズムが本当に効率的かどうかを教えてくれることです。たとえば、共有メモリに使用される /dev/shm 内のファイルは常に RAM に保持されるか、ある時点でハード ドライブに書き込まれる可能性がある (パフォーマンス ヒット) と考えるのは正しいでしょうか? 注意すべき落とし穴はありますか?

現状では、おそらく現在のプロジェクトにはもっと簡単な方法を使用するつもりですが、将来のためにツールボックスに入れておくために、これを理解しておくとよいでしょう。

お時間をいただきありがとうございます。