C++工程实践(7)：iostream的用途与局限

因此，iostream 并不适合在多线程程序中做 logging。

iostream 的局限

根据以上分析，我们可以归纳 iostream 的局限：

• 输入方面，istream 不适合输入带格式的数据，因为“纠错”能力不强，进一步的分析请见孟岩写的《契约思想的一个反面案例》，孟岩说“复杂的设计必然带来复杂的使用规则，而面对复杂的使用规则，用户是可以投票的，那就是你做你的，我不用！”可谓鞭辟入里。如果要用 istream，我推荐的做法是用 getline() 读入一行数据，然后用正则表达式来判断内容正误，并做分组，然后用 strtod/strtol 之类的函数做类型转换。这样似乎更容易写出健壮的程序。
• 输出方面，ostream 的格式化输出非常繁琐，而且写死在代码里，不如 stdio 的小语言那么灵活通用。建议只用作简单的无格式输出。
• log 方面，由于 ostream 没有办法在多线程程序中保证一行输出的完整性，建议不要直接用它来写 log。如果是简单的单线程程序，输出数据量较少的情况下可以酌情使用。当然，产品代码应该用成熟的 logging 库，而不要用其它东西来凑合。
• in-memory 格式化方面，由于 ostringstream 会动态分配内存，它不适合性能要求较高的场合。
• 文件 IO 方面，如果用作文本文件的输入或输出，(i|o)fstream 有上述的缺点；如果用作二进制数据输入输出，那么自己简单封装一个 File class 似乎更好用，也不必为用不到的功能付出代价（后文还有具体例子）。ifstream 的一个用处是在程序启动时读入简单的文本配置文件。如果配置文件是其他文本格式（XML 或 JSON），那么用相应的库来读，也用不到 ifstream。
• 性能方面，iostream 没有兑现“高效性”诺言。iostream 在某些场合比 stdio 快，在某些场合比 stdio 慢，对于性能要求较高的场合，我们应该自己实现字符串转换（见后文的代码与测试）。iostream 性能方面的一个注脚：在线 ACM/ICPC 判题网站上，如果一个简单的题目发生超时错误，那么把其中 iostream 的输入输出换成 stdio，有时就能过关。

既然有这么多局限，iostream 在实际项目中的应用就大为受限了，在这上面投入太多的精力实在不值得。说实话，我没有见过哪个 C++ 产品代码使用 iostream 来作为输入输出设施。http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml#Streams

iostream 的设计有相当多的 WTFs，stackoverflow 有人吐槽说“If you had to judge by today's software engineering standards, would C++'s IOStreams still be considered well-designed?”http://stackoverflow.com/questions/2753060/who-architected-designed-cs-iostreams-and-would-it-still-be-considered-well 。

面向对象的设计

iostream 是个面向对象的 IO 类库，本节简单介绍它的继承体系。

对 iostream 略有了解的人会知道它用了多重继承和虚拟继承，简单地画个类图如下，是典型的菱形继承：

如果加深一点了解，会发现 iostream 现在是模板化的，同时支持窄字符和宽字符。下图是现在的继承体系，同时画出了 fstreams 和 stringstreams。图中方框的第二行是模板的具现化类型，也就是我们代码里常用的具体类型（通过 typedef 定义）。

这个继承体系糅合了面向对象与泛型编程，但可惜它两方面都不讨好。

再进一步加深了解，发现还有一个平行的 streambuf 继承体系，fstream 和 stringstream 的不同之处主要就在于它们使用了不同的 streambuf 具体类型。

再把这两个继承体系画到一幅图里：

注意到 basic_ios 持有了 streambuf 的指针；而 fstreams 和 stringstreams 则分别包含 filebuf 和 stringbuf 的对象。看上去有点像 Bridge 模式。

看了这样巴洛克的设计，有没有人还打算在自己的项目中想通过继承 iostream 来实现自己的 stream，以实现功能扩展么？

面向对象方面的设计缺陷

本节我们分析一下 iostream 的设计违反了哪些 OO 准则。

我们知道，面向对象中的 public 继承需要满足 Liskov 替换原则。（见《Effective C++ 第3版》条款32：确保你的 public 继承模塑出 is-a 关系。《C++ 编程规范》条款 37：public 继承意味可替换性。继承非为复用，乃为被复用。）

在程序里需要用到 ostream 的地方（例如 operator<<），我传入 ofstream 或 ostringstream 都应该能按预期工作，这就是 OO 继承强调的“可替换性”，派生类的对象可以替换基类对象，从而被 operator<<复用。

iostream 的继承体系多次违反了 Liskov 原则，这些地方继承的目的是为了复用基类的代码，下图中我把违规的继承关系用红线标出。

在现有的继承体系中，合理的有：

• ifstream is-a istream
• istringstream is-a istream
• ofstream is-a ostream
• ostringstream is-a ostream
• fstream is-a iostream
• stringstream is-a iostream

我认为不怎么合理的有：

• ios 继承 ios_base，有没有哪种情况下程序代码期待 ios_base 对象，但是客户可以传入一个 ios 对象替代之？如果没有，这里用 public 继承是不是违反 OO 原则？
• istream 继承 ios，有没有哪种情况下程序代码期待 ios 对象，但是客户可以传入一个 istream 对象替代之？如果没有，这里用 public 继承是不是违反 OO 原则？
• ostream 继承 ios，有没有哪种情况下程序代码期待 ios 对象，但是客户可以传入一个 ostream 对象替代之？如果没有，这里用 public 继承是不是违反 OO 原则？
• iostream 多重继承 istream 和 ostream。为什么 iostream 要同时继承两个 non-interface class？这是接口继承还是实现继承？是不是可以用组合(composition)来替代？（见《Effective C++ 第3版》条款38：通过组合模塑出has-a 或“以某物实现”。《C++ 编程规范》条款 34：尽可能以组合代替继承。）

用组合替换继承之后的体系：

注意到在新的设计中，只有真正的 is-a 关系采用了 public 继承，其他均以组合来代替，组合关系以红线表示。新的设计没有用的虚拟继承或多重继承。

其中 iostream 的新实现值得一提，代码结构如下：

class istream;
class ostream;

class iostream
{
 public:
  istream& get_istream();
  ostream& get_ostream();
  virtual ~iostream();
};

这样一来，在需要 iostream 对象表现得像 istream 的地方，调用 get_istream() 函数返回一个 istream 的引用；在需要 iostream 对象表现得像 ostream 的地方，调用 get_ostream() 函数返回一个 ostream 的引用。功能不受影响，而且代码更清晰。（虽然我非常怀疑 iostream 的真正价值，一个东西既可读又可写，说明是个 sophisticated IO 对象，为什么还用这么厚的 OO 封装？）

阳春的 locale

iostream 的故事还不止这些，它还包含一套阳春的 locale/facet 实现，这套实践中没人用的东西进一步增加了 iostream 的复杂度，而且不可避免地影响其性能。Nathan Myers 正是始作俑者http://www.cantrip.org/locale.html 。

ostream 自身定义的针对整数和浮点数的 operator<<成员函数的函数体是：

bool failed =
  use_facet(getloc()).put(
    ostreambuf_iterator(*this), *this, fill(), val).failed();

它会转而调用 num_put::put()，后者会调用 num_put::do_put()，而 do_put() 是个虚函数，没办法 inline。iostream 在性能方面的不足恐怕部分来自于此。这个虚函数白白浪费了把 template 的实现放到头文件应得的好处，编译和运行速度都快不起来。

我没有深入挖掘其中的细节，感兴趣的同学可以移步观看 facet 的继承体系：http://gcc.gnu.org/onlinedocs/libstdc++/libstdc++-html-USERS-4.4/a00431.html

据此分析，我不认为以 iostream 为基础的上层程序库（比方说那些克服 iostream 格式化方面的缺点的库）有多大的实用价值。

臆造抽象

孟岩评价 “ iostream 最大的缺点是臆造抽象”，我非常赞同他老人家的观点。

这个评价同样适用于 Java 那一套叠床架屋的 InputStream/OutputStream/Reader/Writer 继承体系，.NET 也搞了这么一套繁文缛节。

乍看之下，用 input stream 表示一个可以“读”的数据流，用 output stream 表示一个可以“写”的数据流，屏蔽底层细节，面向接口编程，“符合面向对象原则”，似乎是一件美妙的事情。但是，真实的世界要残酷得多。

IO 是个极度复杂的东西，就拿最常见的 memory stream、file stream、socket stream 来说，它们之间的差异极大：

• 是单向 IO 还是双向 IO。只读或者只写？还是既可读又可写？
• 顺序访问还是随机访问。可不可以 seek？可不可以退回 n 字节？
• 文本数据还是二进制数据。格式有误怎么办？如何编写健壮的处理输入的代码？
• 有无缓冲。write 500 字节是否能保证完全写入？有没有可能只写入了 300 字节？余下 200 字节怎么办？
• 是否阻塞。会不会返回 EWOULDBLOCK 错误？
• 有哪些出错的情况。这是最难的，memory stream 几乎不可能出错，file stream 和 socket stream 的出错情况完全不同。socket stream 可能遇到对方断开连接，file stream 可能遇到超出磁盘配额。

根据以上列举的初步分析，我不认为有办法设计一个公共的基类把各方面的情况都考虑周全。各种 IO 设施之间共性太小，差异太大，例外太多。如果硬要用面向对象来建模，基类要么太瘦（只放共性，这个基类包含的 interface functions 没多大用），要么太肥（把各种 IO 设施的特性都包含进来，这个基类包含的 interface functions 很多，但是不是每一个都能调用）。

C 语言对此的解决办法是用一个 int 表示 IO 对象（file 或 PIPE 或 socket），然后配以 read()/write()/lseek()/fcntl() 等一系列全局函数，程序员自己搭配组合。这个做法我认为比面向对象的方案要简洁高效。

iostream 在性能方面没有比 stdio 高多少，在健壮性方面多半不如 stdio，在灵活性方面受制于本身的复杂设计而难以让使用者自行扩展。目前看起来只适合一些简单的要求不高的应用，但是又不得不为它的复杂设计付出运行时代价，总之其定位有点不上不下。

在实际的项目中，我们可以提炼出一些简单高效的 strip-down 版本，在获得便利性的同时避免付出不必要的代价。

我认为以 operator<<来输出数据非常适合 logging，因此写了一个简单的 LogStream。代码不到 300行，完全独立于 iostream。

• 接口 https://github.com/chenshuo/recipes/blob/master/logging/LogStream.h
• 实现 https://github.com/chenshuo/recipes/blob/master/logging/LogStream.cc
• 单元测试 https://github.com/chenshuo/recipes/blob/master/logging/LogStream_test.cc
• 性能测试 https://github.com/chenshuo/recipes/blob/master/logging/LogStream_bench.cc

这个 LogStream 做到了类型安全和类型可扩展。它不支持定制格式化、不支持 locale/facet、没有继承、buffer 也没有继承与虚函数、没有动态分配内存、buffer 大小固定。简单地说，适合 logging 以及简单的字符串转换。

LogStream 的接口定义是

class LogStream : boost::noncopyable
{
  typedef LogStream self;
 public:
  typedef detail::FixedBuffer Buffer;
  LogStream();

  self& operator<<(bool);

  self& operator<<(short);
  self& operator<<(unsigned short);
  self& operator<<(int);
  self& operator<<(unsigned int);
  self& operator<<(long);
  self& operator<<(unsigned long);
  self& operator<<(long long);
  self& operator<<(unsigned long long);

  self& operator<<(const void*);

  self& operator<<(float);
  self& operator<<(double);
  // self& operator<<(long double);

  self& operator<<(char);
  // self& operator<<(signed char);
  // self& operator<<(unsigned char);

  self& operator<<(const char*);
  self& operator<<(const string&);

  const Buffer& buffer() const { return buffer_; }
  void resetBuffer() { buffer_.reset(); }

 private:
  Buffer buffer_;
};

LogStream 本身不是线程安全的，它不适合做全局对象。正确的使用方式是每条 log 消息构造一个 LogStream，用完就扔。LogStream 的成本极低，这么做不会有什么性能损失。

目前这个 logging 库还在开发之中，只完成了 LogStream 这一部分。将来可能改用动态分配的 buffer，这样方便在线程之间传递数据。

整数到字符串的高效转换

muduo::LogStream 的整数转换是自己写的，用的是 Matthew Wilson 的算法，见 http://blog.csdn.net/solstice/article/details/5139302 。这个算法比 stdio 和 iostream 都要快。

浮点数到字符串的高效转换

目前 muduo::LogStream 的浮点数格式化采用的是 snprintf() 所以从性能上与 stdio 持平，比 ostream 快一些。

浮点数到字符串的转换是个复杂的话题，这个领域 20 年以来没有什么进展（目前的实现大都基于 David M. Gay 在 1990 年的工作《Correctly Rounded Binary-Decimal and Decimal-Binary Conversions》，代码http://netlib.org/fp/），直到 2010 年才有突破。

Florian Loitsch 发明了新的更快的算法 Grisu3，他的论文《Printing floating-point numbers quickly and accurately with integers》发表在 PLDI 2010，代码见Google V8 引擎，还有这里http://code.google.com/p/double-conversion/ 。有兴趣的同学可以阅读这篇博客http://www.serpentine.com/blog/2011/06/29/here-be-dragons-advances-in-problems-you-didnt-even-know-you-had/ 。

将来 muduo::LogStream 可能会改用 Grisu3 算法实现浮点数转换。

性能对比

由于 muduo::LogStream 抛掉了很多负担，可以预见它的性能好于 ostringstream 和 stdio。我做了一个简单的性能测试，结果如下。

从上表看出，ostreamstream 有时候比 snprintf 快，有时候比它慢，muduo::LogStream 比它们两个都快得多（double 类型除外）。

泛型编程

其他程序库如何使用 LogStream 作为输出呢？办法很简单，用模板。

前面我们定义了 Date class 针对 std::ostream 的 operator<<，只要稍作修改就能同时适用于 std::ostream 和 LogStream。而且 Date 的头文件不再需要 include ，降低了耦合。

 class Date
 {
  public:
   Date(int year, int month, int day)
     : year_(year), month_(month), day_(day)
   {
   }

-  void writeTo(std::ostream& os) const
+  template
+  void writeTo(OStream& os) const
   {
     char buf[32];
     snprintf(buf, sizeof buf, "%d-%02d-%02d", year_, month_, day_);
     os <   }

  private:
   int year_, month_, day_;
 };

-std::ostream& operator<<(std::ostream& os, const Date& date)
+template
+OStream& operator<<(OStream& os, const Date& date)
 {
   date.writeTo(os);
   return os;
 }

举两个例子， Kyoto Cabinet 和 Google leveldb。

Google leveldb

Google leveldb 是一个高效的持久化 key-value db。

它定义了三个精简的 interface：

• SequentialFile http://code.google.com/p/leveldb/source/browse/trunk/include/leveldb/env.h#154
• RandomAccessFile http://code.google.com/p/leveldb/source/browse/trunk/include/leveldb/env.h#178
• WritableFile http://code.google.com/p/leveldb/source/browse/trunk/include/leveldb/env.h#197

接口函数如下

struct Slice {
  const char* data_;
  size_t size_;
};

// A file abstraction for reading sequentially through a file
class SequentialFile {
 public:
  SequentialFile() { }
  virtual ~SequentialFile();

  virtual Status Read(size_t n, Slice* result, char* scratch) = 0;
  virtual Status Skip(uint64_t n) = 0;
};

// A file abstraction for randomly reading the contents of a file.
class RandomAccessFile {
 public:
  RandomAccessFile() { }
  virtual ~RandomAccessFile();

  virtual Status Read(uint64_t offset, size_t n, Slice* result,
                      char* scratch) cOnst= 0;
};

// A file abstraction for sequential writing.  The implementation
// must provide buffering since callers may append small fragments
// at a time to the file.
class WritableFile {
 public:
  WritableFile() { }
  virtual ~WritableFile();

  virtual Status Append(const Slice& data) = 0;
  virtual Status Close() = 0;
  virtual Status Flush() = 0;
  virtual Status Sync() = 0;
};

leveldb 明确区分 input 和 output，进一步它又把 input 分为 sequential 和 random access，然后提炼出了三个简单的接口，每个接口只有屈指可数的几个函数。这几个接口在各个平台下的实现也非常简单明了（http://code.google.com/p/leveldb/source/browse/trunk/util/env_posix.cc#35http://code.google.com/p/leveldb/source/browse/trunk/util/env_chromium.cc#176），一看就懂。

注意这三个接口使用了虚函数，我认为这是正当的，因为一次 IO 往往伴随着 context switch，虚函数的开销比起 context switch 来可以忽略不计。相反，iostream 每次 operator<<() 就调用虚函数，我认为不太明智。

Kyoto Cabinet

Kyoto Cabinet 也是一个 key-value db，是前几年流行的 Tokyo Cabinet 的升级版。它采用了与 leveldb 不同的文件抽象。

KC 定义了一个 File class，同时包含了读写操作，这是个 fat interface。http://fallabs.com/kyotocabinet/api/classkyotocabinet_1_1File.html

在具体实现方面，它没有使用虚函数，而是采用 #ifdef 来区分不同的平台（见 http://code.google.com/p/read-taobao-code/source/browse/trunk/tair/src/storage/kdb/kyotocabinet/kcfile.cc），等于把两份独立的代码写到了同一个文件里边。

相比之下，Google leveldb 的做法更高明一些。

在 C++ 项目里边自己写个 File class，把项目用到的文件 IO 功能简单封装一下（以 RAII 手法封装 FILE* 或者 file descriptor 都可以，视情况而定），通常就能满足需要。记得把拷贝构造和赋值操作符禁用，在析构函数里释放资源，避免泄露内部的 handle，这样就能自动避免很多 C 语言文件操作的常见错误。

如果要用 stream 方式做 logging，可以抛开繁重的 iostream 自己写一个简单的 LogStream，重载几个 operator<<，用起来一样方便；而且可以用 stack buffer，轻松做到线程安全。