私は、アルゴリズムが情報の最小単位としてビットを処理しなければならないといういくつかのアイデアを実験しています。これは、ユーザーがUNIXシェルパイプラインのように「パイプライン」の一部を再配置できるモジュラーアプリケーションです。これらのアルゴリズムは、フレーミング、圧縮、解凍、エラーチェック、修正などのさまざまなことを行います。ノイズの導入、検出、除去など。
それらはビットレベルで機能するため、アルゴリズムは、たとえば、5ビットの入力を受け取り、19ビットの出力を生成する場合があります。入力と出力がバイトの倍数になることはめったにありません。
メモリ内およびスレッド間のビットストリームの操作は、の助けを借りて問題ありstd::vector<bool>ませんが、このビットストリームをどこかから取得して保存する必要があり、できれば次のような実際のコマンドラインパイプラインを実行できるはずです。
prog1 < bitsource.dat | prog2 -opts | prog3 -opts > bitsink.dat
あるいは：
prog1 | prog2 | ssh user@host /bin/sh -c "prog3 | prog4 > /dev/dsp"
問題は、標準ストリーム（stdinおよびstdout）がバイト指向であるため、これらのビットを効率的にシリアル化する方法です。入力と出力のビット数がバイトの倍数でない状況を処理する必要があります。
現在、各ビットを0x30または0x31（"0"または"1"）のいずれかのバイトに拡張することによってそれを行う概念実証が機能しています。明らかに、これによりデータのサイズが8倍になり、必要なスペースと帯域幅の8倍のスペースと帯域幅が消費されます。これらのビットをより効率的にパックしたいと思います。
私が検討している代替案の1つは、出力のビットをバッファリングし、Lengthヘッダーとそれに続くceiling（Length / 8）バイトのデータで構成されるブロックを生成し、必要に応じて出力をフラッシュするプロトコルです。
しかし、作成されたプロトコルを作成する代わりに、誰かがすでにこれらの要件を持っているかどうか、あなたの経験は何ですか、そしてこれのための標準プロトコル（任意のビット数のシリアル化）がすでにあるかどうかを知りたいです使用する。おそらく誰かがすでにこの問題を抱えており、互換性のないフォーマットの急増を避けるために、このアプリケーションでも使用できる何らかの形式のエンコーディングをすでに使用しています。