C++二进制输输出流接口设计.pdfVIP

C++ C++ CC++++二进制输入输出流接口设计 提到输入输出流，作为CPPer很自然的就会想到std::iostream，对于文本流的处理，iostream 可以说足够强大，应付一般复杂度的需求毫无压力。对二进制流处理却只能用“简陋”来形容，悲 催的是，作为一个在多媒体软件领域默默耕耘多年的码农日常打交道最多的偏偏就是二进制流。 前些年流行过一本书叫做什么男人来自火星女人来自金星之类的，同样的，如果说文本流来自火 星那二进制流就是来自金星。对一个文本流，我们可能期望这样的接口函数： 1 string text = stream.get_line(); // 基础接口 2 string word = stream.get_word(); // 增强接口 而对二进制流，我们期望的接口可能是这个样子的： 1 int read_bytes = stream.read(buffer, size); // 基本接口 2 int value = stream.read_int32(); // 增强接口 做为iostream灵魂的插入 提取运算符/ (/)重载对文本流来说是神一般的存在，但在二 进制流中却完全无法使用，因为二进制流需要精确到byte（甚至bit）的控制，所以会有下面这 样的接口： int v1 = stream.read_uint16(); // 读取short int int v2 = stream.read_int16(); // 读取unsigned short int int v3 = stream.read_uint24(); // 读取3字节无符号整型，没错是3字节24位 int v4 = stream.read_int24(); // 想想这个函数有多变态！ 基于编译期推导的运算符重载很难满足类似的需求。在我看来，把两类方法合并在同一个类中是 得不偿失的，核心需求几乎没什么相似之处，非核心的需求则无关紧要，而且基本上不会有既是 iostream (wo) (cuo) (le) (ma) 文本流又是二进制流的情况出现。 偏偏就这么做了，对此，只 能 呵 呵 了。 二进制流按照流的方向可以划分为输入流和输出流（废话）；按另外一个纬度上则可以划分为顺 序访问流和可随机访问流，两者最主要的区别是是否支持定位操作(seek)，前者不支持，后者支 持，比如标准输入输出流就是顺序访问流，而文件流一般都是可随机访问流。站在更高的层次上 来理解，顺序访问流内置了一个时间箭头，既不能回头也不能跳跃，可随机访问流则是内置的空 间轴，没有方向性（或者说方向性很弱），如果你愿意完全可以从一个文件的尾部往头部读。因 此带有时间属性的实时流一般是顺序访问流，比如录音、录屏产生的数据流，比如在线直播视频 的直播流。 两个纬度各两个分类共四种组合，由此我们就可以设计一个 newbility的架构出来了： 哈哈，是不是很强大，是不是……怕了？……怕了就对了，这还只是抽象接口类，如果再把实现 类以及各种派生考虑进去，这个系统的复杂度至少还要增加两倍。 …… 上面的图是开个玩笑，图中的系统是典型的臆造抽象，连过度设计都算不上，甚至不如没有设计。 DirectShow baseclasses 虽然夸张了些，但现实中也不是没有犯了类似错误的系统，比如 的 内 部的实现代码就颇有些神似的地方（说出这样的话，我对DirectShow的怨念得有多深啊……）。 解决任何问题的第一步首先就是简化问题，也就是抓住主要矛盾，忽略次要矛盾。至少在曾经 某一段时间，CPPer特别追求精致的设计，而精致的设计往往首先就把简单的问题复杂化了，还 记得那个经典的C++版的HelloWorld吗？精致设计的目的本是为了代码复用，而现实却是： 越简单的代码越容易复用，越是精心设计的代码越容易因为复杂而难以复用。回到我们的问题， 首先要找到主要矛盾，也就是核心需求：一组能应付大部分日常任务的简单的输入和输出流， 注意，这里用的是“输入和输出流”而不是“输入输出流”。事实上，在实际的开发工作中很少会遇 到要求一个流即是输入流又是输出流的情况