【发布时间】：2011-01-03 17:08:09
【问题描述】：
我正在尝试一些想法，其中算法必须将比特作为其最小的信息单位。这是一个模块化应用程序，用户可以像 unix shell 管道一样重新排列“管道”的一部分。这些算法做各种各样的事情，比如成帧、压缩、解压缩、错误检查和纠正；引入、检测和去除噪声等。
由于它们在位级别上工作，例如，算法可能会采用 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 倍。我希望以更有效的方式打包这些位。
我正在考虑的一个替代方案是一种协议，它缓冲输出中的位并生成由 Length 标头后跟 ceiling(Length/8) 组成的块字节的数据，在适当的时候刷新输出。
但不是创建一个虚构的协议，我想知道是否有人已经有这些要求，你的经验是什么，以及是否已经有一些标准协议（任意位数的序列化）我可以使用。也许有人已经遇到了这个问题，并且已经在使用某种形式的编码，也可以在这个应用程序中使用，以避免不兼容格式的扩散。
【问题讨论】：
-
“当然，这样效率很低”？真的吗？测量时间，考虑到一些 I/O 系统有多慢，它实际上可能非常好。你测量过这个吗？还是您在谈论 8x1 的尺寸扩展？您在寻找什么样的效率？
-
@S.Lott：是的，我说的是尺寸增加了八倍。空间（存储）、带宽（通过网络传输）和处理器（输入/输出期间的转换）效率是关注点，特别是空间和带宽。八倍的增长很少被忽视。如果一切顺利，这应该用于实时应用程序。我想现在把它做好，而不是遇到一个需要以后重写所有东西的瓶颈。
-
请更新这个问题，让它完全清楚。这是你的问题；你可以改进它。一长串的 cmets 很难整合成一个明确的问题。
-
@S.Lott：完成。澄清一点。
标签： language-agnostic serialization stdout pipeline bitstream