陳碩 (giantchen_AT_gmail)
http://blog.csdn.net/Solstice http://weibo.com/giantchen
陳碩關于 C++ 工程實踐的系列文章： http://blog.csdn.net/Solstice/category/802325.aspx
陳碩博客文章合集下載： http://blog.csdn.net/Solstice/archive/2011/02/24/6206154.aspx
本作品采用“Creative Commons 署名-非商業性使用-禁止演繹 3.0 Unported 許可協議(cc by-nc-nd)”進行許可。http://creativecommons.org/licenses/by-nc-nd/3.0/
本文主要考慮 x86 Linux 平臺，不考慮跨平臺的可移植性，也不考慮國際化(i18n)，但是要考慮 32-bit 和 64-bit 的兼容性。本文以 stdio 指代 C 語言的 scanf/printf 系列格式化輸入輸出函數。本文注意區分“編程初學者”和“C++初學者”，二者含義不同。
摘要：C++ iostream 的主要作用是讓初學者有一個方便的命令行輸入輸出試驗環境，在真實的項目中很少用到 iostream，因此不必把精力花在深究 iostream 的格式化與 manipulator。iostream 的設計初衷是提供一個可擴展的類型安全的 IO 機制，但是后來莫名其妙地加入了 locale 和 facet 等累贅。其整個設計復雜不堪，多重+虛擬繼承的結構也很巴洛克，性能方面幾無亮點。iostream 在實際項目中的用處非常有限，為此投入過多學習精力實在不值。
stdio 格式化輸入輸出的缺點
1. 對編程初學者不友好
看看下面這段簡單的輸入輸出代碼。
#include <stdio.h>
int main()
{
int i;
short s;
float f;
double d;
char name[80];
scanf("%d %hd %f %lf %s", &i, &s, &f, &d, name);
printf("%d %d %f %f %s", i, s, f, d, name);
}
注意到其中
- 輸入和輸出用的格式字符串不一樣。輸入 short 要用 %hd，輸出用 %d；輸入 double 要用 %lf，輸出用 %f。
- 輸入的參數不統一。對于 i、s、f、d 等變量，在傳入 scanf() 的時候要取地址(&)，而對于 name，則不用取地址。
讀者可以試一試如何用幾句話向剛開始學編程的初學者解釋上面兩條背后原因（涉及到傳遞函數不定參數時的類型轉換，函數調用棧的內存布局，指針的意義，字符數組退化為字符指針等等），如果一開始解釋不清，只好告訴學生“這是規定”。
- 緩沖區溢出的危險。上面的例子在讀入 name 的時候沒有指定大小，這是用 C 語言編程的安全漏洞的主要來源。應該在一開始就強調正確的做法，避免養成錯誤的習慣。正確而安全的做法如 Bjarne Stroustrup 在《Learning Standard C++ as a New Language》所示：
#include <stdio.h>
int main()
{
const int max = 80;
char name[max];
char fmt[10];
sprintf(fmt, "%%%ds", max - 1);
scanf(fmt, name);
printf("%s\n", name);
}
這個動態構造格式化字符串的做法恐怕更難向初學者解釋。
2. 安全性(security)
C 語言的安全性問題近十幾年來引起了廣泛的注意，C99 增加了 snprintf() 等能夠指定輸出緩沖區大小的函數，輸出方面的安全性問題已經得到解決；輸入方面似乎沒有太大進展，還要靠程序員自己動手。
考慮一個簡單的編程任務：從文件或標準輸入讀入一行字符串，行的長度不確定。我發現沒有哪個 C 語言標準庫函數能完成這個任務，除非 roll your own。
首先，gets() 是錯誤的，因為不能指定緩沖區的長度。
其次，fgets() 也有問題。它能指定緩沖區的長度，所以是安全的。但是程序必須預設一個長度的最大值，這不滿足題目要求“行的長度不確定”。另外，程序無法判斷 fgets() 到底讀了多少個字節。為什么？考慮一個文件的內容是 9 個字節的字符串 "Chen\000Shuo"，注意中間出現了 '\0' 字符，如果用 fgets() 來讀取，客戶端如何知道 "\000Shuo" 也是輸入的一部分？畢竟 strlen() 只返回 4，而且整個字符串里沒有 '\n' 字符。
最后，可以用 glibc 定義的 getline(3) 函數來讀取不定長的“行”。這個函數能正確處理各種情況，不過它返回的是 malloc() 分配的內存，要求調用端自己 free()。
3. 類型安全(type-safe)
如果 printf() 的整數參數類型是 int、long 等標準類型， 那么 printf() 的格式化字符串很容易寫。但是如果參數類型是 typedef 的類型呢？
如果你想在程序中用 printf 來打印日志，你能一眼看出下面這些類型該用 "%d" "%ld" "%lld" 中的哪一個來輸出？你的選擇是否同時兼容 32-bit 和 64-bit 平臺？
- clock_t。這是 clock(3) 的返回類型
- dev_t。這是 mknod(3) 的參數類型
- in_addr_t、in_port_t。這是 struct sockaddr_in 的成員類型
- nfds_t。這是 poll(2) 的參數類型
- off_t。這是 lseek(2) 的參數類型，麻煩的是，這個類型與宏定義 _FILE_OFFSET_BITS 有關。
- pid_t、uid_t、gid_t。這是 getpid(2) getuid(2) getgid(2) 的返回類型
- ptrdiff_t。printf() 專門定義了 "t" 前綴來支持這一類型（即使用 "%td" 來打?。?
- size_t、ssize_t。這兩個類型到處都在用。printf() 為此專門定義了 "z" 前綴來支持這兩個類型（即使用 "%zu" 或 "%zd" 來打?。?。
- socklen_t。這是 bind(2) 和 connect(2) 的參數類型
- time_t。這是 time(2) 的返回類型，也是 gettimeofday(2) 和 clock_gettime(2) 的輸出結構體的成員類型
如果在 C 程序里要正確打印以上類型的整數，恐怕要費一番腦筋?！禩he Linux Programming Interface》的作者建議（3.6.2節）先統一轉換為 long 類型再用 "%ld" 來打印；對于某些類型仍然需要特殊處理，比如 off_t 的類型可能是 long long。
還有，int64_t 在 32-bit 和 64-bit 平臺上是不同的類型，為此，如果程序要打印 int64_t 變量，需要包含 <inttypes.h> 頭文件，并且使用 PRId64 宏：
#include <stdio.h>
#define __STDC_FORMAT_MACROS
#include <inttypes.h>
int main()
{
int64_t x = 100;
printf("%" PRId64 "\n", x);
printf("%06" PRId64 "\n", x);
}
muduo 的 Timestamp 使用了 PRId64 http://code.google.com/p/muduo/source/browse/trunk/muduo/base/Timestamp.cc#25
Google C++ 編碼規范也提到了 64-bit 兼容性： http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml#64-bit_Portability
這些問題在 C++ 里都不存在，在這方面 iostream 是個進步。
C stdio 在類型安全方面原本還有一個缺點，即格式化字符串與參數類型不匹配會造成難以發現的 bug，不過現在的編譯器已經能夠檢測很多這種錯誤：
int main()
{
double d = 100.0;
// warning: format '%d' expects type 'int', but argument 2 has type 'double'
printf("%d\n", d);
short s;
// warning: format '%d' expects type 'int*', but argument 2 has type 'short int*'
scanf("%d", &s);
size_t sz = 1;
// no warning
printf("%zd\n", sz);
}
4. 不可擴展？
C stdio 的另外一個缺點是無法支持自定義的類型，比如我寫了一個 Date class，我無法像打印 int 那樣用 printf 來直接打印 Date 對象。
struct Date
{
int year, month, day;
};
Date date;
printf("%D", &date); // WRONG
Glibc 放寬了這個限制，允許用戶調用 register_printf_function(3) 注冊自己的類型，當然，前提是與現有的格式字符不沖突（這其實大大限制了這個功能的用處，現實中也幾乎沒有人真的去用它）。http://www.gnu.org/s/hello/manual/libc/Printf-Extension-Example.html http://en.wikipedia.org/wiki/Printf#Custom_format_placeholders
5. 性能
C stdio 的性能方面有兩個弱點。
- 使用一種 little language （現在流行叫 DSL）來配置格式。固然有利于緊湊性和靈活性，但損失了一點點效率。每次打印一個整數都要先解析 "%d" 字符串，大多數情況下不是問題，某些場合需要自己寫整數到字符串的轉換。
- C locale 的負擔。locale 指的是不同語種對“什么是空白”、“什么是字母”，“什么是小數點”有不同的定義（德語里邊小數點是逗號，不是句點）。C 語言的 printf()、scanf()、isspace()、isalpha()、ispunct()、strtod() 等等函數都和 locale 有關，而且可以在運行時動態更改。就算是程序只使用默認的 "C" locale，任然要為這個靈活性付出代價。
iostream 的設計初衷
iostream 的設計初衷包括克服 C stdio 的缺點，提供一個高效的可擴展的類型安全的 IO 機制。“可擴展”有兩層意思，一是可以擴展到用戶自定義類型，而是通過繼承 iostream 來定義自己的 stream，本文把前一種稱為“類型可擴展”后一種稱為“功能可擴展”。
“類型可擴展”和“類型安全”都是通過函數重載來實現的。
iostream 對初學者很友好，用 iostream 重寫與前面同樣功能的代碼：
#include <iostream>
#include <string>
using namespace std;
int main()
{
int i;
short s;
float f;
double d;
string name;
cin >> i >> s >> f >> d >> name;
cout << i << " " << s << " " << f << " " << d << " " << name << endl;
}
這段代碼恐怕比 scanf/printf 版本容易解釋得多，而且沒有安全性(security)方面的問題。
我們自己的類型也可以融入 iostream，使用起來與 built-in 類型沒有區別。這主要得力于 C++ 可以定義 non-member functions/operators。
#include <ostream> // 是不是太重量級了？
class Date
{
public:
Date(int year, int month, int day)
: year_(year), month_(month), day_(day)
{
}
void writeTo(std::ostream& os) const
{
os << year_ << '-' << month_ << '-' << day_;
}
private:
int year_, month_, day_;
};
std::ostream& operator<<(std::ostream& os, const Date& date)
{
date.writeTo(os);
return os;
}
int main()
{
Date date(2011, 4, 3);
std::cout << date << std::endl;
// 輸出 2011-4-3
}
iostream 憑借這兩點（類型安全和類型可擴展），基本克服了 stdio 在使用上的不便與不安全。如果 iostream 止步于此，那它將是一個非常便利的庫，可惜它前進了另外一步。
iostream 與標準庫其他組件的交互
不同于標準庫其他 class 的“值語意”，iostream 是“對象語意”，即 iostream 是 non-copyable。這是正確的，因為如果 fstream 代表一個文件的話，拷貝一個 fstream 對象意味著什么呢？表示打開了兩個文件嗎？如果銷毀一個 fstream 對象，它會關閉文件句柄，那么另一個 fstream copy 對象會因此受影響嗎？
C++ 同時支持“數據抽象”和“面向對象編程”，其實主要就是“值語意”與“對象語意”的區別，我發現不是每個人都清楚這一點，這里多說幾句。標準庫里的 complex<> 、pair<>、vector<>、 string 等等都是值語意，拷貝之后就與原對象脫離關系，就跟拷貝一個 int 一樣。而我們自己寫的 Employee class、TcpConnection class 通常是對象語意，拷貝一個 Employee 對象是沒有意義的，一個雇員不會變成兩個雇員，他也不會領兩份薪水?？截?TcpConnection 對象也沒有意義，系統里邊只有一個 TCP 連接，拷貝 TcpConnection 對象不會讓我們擁有兩個連接。因此如果在 C++ 里做面向對象編程，寫的 class 通常應該禁用 copy constructor 和 assignment operator，比如可以繼承 boost::noncopyable。對象語意的類型不能直接作為標準容器庫的成員。另一方面，如果要寫一個圖形程序，其中用到三維空間的向量，那么我們可以寫 Vector3D class，它應該是值語意的，允許拷貝，并且可以用作標準容器庫的成員，例如 vector<Vector3D> 表示一條三維的折線。
C stdio 的另外一個缺點是 FILE* 可以隨意拷貝，但是只要關閉其中一個 copy，其他 copies 也都失效了，跟空懸指針一般。這其實不光是 C stdio 的缺點，整個 C 語言對待資源（malloc 得到的內存，open() 打開的文件，socket() 打開的連接）都是這樣，用整數或指針來代表（即“句柄”）。而整數和指針類型的“句柄”是可以隨意拷貝的，很容易就造成重復釋放、遺漏釋放、使用已經釋放的資源等等常見錯誤。這是因為 C 語言錯誤地讓“對象語言”的東西變成了值語意。
iostream 禁止拷貝，利用對象的生命期來明確管理資源（如文件），很自然地就避免了 C 語言易犯的錯誤。這就是 RAII，一種重要且獨特的 C++ 編程手法。
std::string
iostream 可以與 string 配合得很好。但是有一個問題：誰依賴誰？
std::string 的 operator << 和 operator >> 是如何聲明的？"string" 頭文件在聲明這兩個 operators 的時候要不要 include "iostream" ？
iostream 和 string 都可以單獨 include 來使用，顯然 iostream 頭文件里不會定義 string 的 << 和 >> 操作。但是，如果"string"要include "iostream"，豈不是讓 string 的用戶被迫也用了 iostream？編譯 iostream 頭文件可是相當的慢?。ㄒ驗?iostream 是 template，其實現代碼都放到了頭文件中）。
標準庫的解決辦法是定義 iosfwd 頭文件，其中包含 istream 和 ostream 等的前向聲明 (forward declarations)，這樣 "string" 頭文件在定義輸入輸出操作符時就可以不必包含 "iostream"，只需要包含簡短得多的 "iosfwd"。我們自己寫程序也可借此學習如何支持可選的功能。
值得注意的是，istream::getline() 成員函數的參數類型是 char*，因為 "istream" 沒有包含 "string"，而我們常用的 std::getline() 函數是個 non-member function，定義在 "string" 里邊。
std::complex
標準庫的復數類 complex 的情況比較復雜。使用 complex 會自動包含 sstream，后者會包含 istream 和 ostream，這是個不小的負擔。問題是，為什么？
它的 operator >> 操作比 string 復雜得多，如何應對格式不正確的情況？輸入字符串不會遇到格式不正確，但是輸入一個復數可能遇到各種問題，比如數字的格式不對等。我懷疑有誰會真的在產品項目里用 operator >> 來讀入字符方式表示的復數，這樣的代碼的健壯性如何保證?；谕瑯拥睦碛桑艺J為產品代碼中應該避免用 istream 來讀取帶格式的內容，后面也不再談 istream 的缺點，它已經被秒殺。
它的 operator << 也很奇怪，它不是直接使用參數 ostream& os 對象來輸出，而是先構造 ostringstream，輸出到該 string stream，再把結果字符串輸出到 ostream。簡化后的代碼如下：
template<typename T>
std::ostream& operator<<(std::ostream& os, const std::complex<T>& x)
{
std::ostringstream s;
s << '(' << x.real() << ',' << x.imag() << ')';
return os << s.str();
}
注意到 ostringstream 會用到動態分配內存，也就是說，每輸出一個 complex 對象就會分配釋放一次內存，效率堪憂。
根據以上分析，我認為 iostream 和 complex 配合得不好，但是它們耦合得更緊密（與 string/iostream 相比），這可能是個不得已的技術限制吧（complex 是 template，其 operator<< 必須在頭文件中定義，而這個定義又用到了 ostringstream，不得已包含了 iostream 的實現）。
如果程序要對 complex 做 IO，從效率和健壯性方面考慮，建議不要使用 iostream。
iostream 在使用方面的缺點
在簡單使用 iostream 的時候，它確實比 stdio 方便，但是深入一點就會發現，二者可說各擅勝場。下面談一談 iostream 在使用方面的缺點。
1. 格式化輸出很繁瑣
iostream 采用 manipulator 來格式化，如果我想按照 2010-04-03 的格式輸出前面定義的 Date class，那么代碼要改成：
--- 02-02.cc 2011-07-16 16:40:05.000000000 +0800
+++ 04-01.cc 2011-07-16 17:10:27.000000000 +0800
@@ -1,4 +1,5 @@
#include <iostream>
+#include <iomanip>
class Date
{
@@ -10,7 +11,9 @@
void writeTo(std::ostream& os) const
{
- os << year_ << '-' << month_ << '-' << day_;
+ os << year_ << '-'
+ << std::setw(2) << std::setfill('0') << month_ << '-'
+ << std::setw(2) << std::setfill('0') << day_;
}
private:
假如用 stdio，會簡短得多，因為 printf 采用了一種表達能力較強的小語言來描述輸出格式。
--- 04-01.cc 2011-07-16 17:03:22.000000000 +0800
+++ 04-02.cc 2011-07-16 17:04:21.000000000 +0800
@@ -1,5 +1,5 @@
#include <iostream>
-#include <iomanip>
+#include <stdio.h>
class Date
{
@@ -11,9 +11,9 @@
void writeTo(std::ostream& os) const
{
- os << year_ << '-' << month_ << '-' << day_;
+ char buf[32];
+ snprintf(buf, sizeof buf, "%d-%02d-%02d", year_, month_, day_);
+ os << buf;
}
private:
使用小語言來描述格式還帶來另外一個好處：外部可配置。
2. 外部可配置性
比方說，我想用一個外部的配置文件來定義日期的格式。C stdio 很好辦，把格式字符串 "%d-%02d-%02d" 保存到配置里就行。但是 iostream 呢？它的格式是寫死在代碼里的，靈活性大打折扣。
再舉一個例子，程序的 message 的多語言化。
const char* name = "Shuo Chen";
int age = 29;
printf("My name is %1$s, I am %2$d years old.\n", name, age);
cout << "My name is " << name << ", I am " << age << " years old." << endl;
對于 stdio，要讓這段程序支持中文的話，把代碼中的"My name is %1$s, I am %2$d years old.\n",
替換為 "我叫%1$s，今年%2$d歲。\n" 即可。也可以把這段提示語做成資源文件，在運行時讀入。而對于 iostream，恐怕沒有這么方便，因為代碼是支離破碎的。
C stdio 的格式化字符串體現了重要的“數據就是代碼”的思想，這種“數據”與“代碼”之間的相互轉換是程序靈活性的根源，遠比 OO 更為靈活。
3. stream 的狀態
如果我想用 16 進制方式輸出一個整數 x，那么可以用 hex 操控符，但是這會改變 ostream 的狀態。比如說
int x = 8888;
cout << hex << showbase << x << endl; // forgot to reset state
cout << 123 << endl;
這這段代碼會把 123 也按照 16 進制方式輸出，這恐怕不是我們想要的。
再舉一個例子，setprecision() 也會造成持續影響：
double d = 123.45;
printf("%8.3f\n", d);
cout << d << endl;
cout << setw(8) << fixed << setprecision(3) << d << endl;
cout << d << endl;
輸出是：
$ ./a.out
123.450
123.45 # default cout format
123.450 # our format
123.450 # side effects
可見代碼中的 setprecision() 影響了后續輸出的精度。注意 setw() 不會造成影響，它只對下一個輸出有效。
這說明，如果使用 manipulator 來控制格式，需要時刻小心防止影響了后續代碼。而使用 C stdio 就沒有這個問題，它是“上下文無關的”。
4. 知識的通用性
在 C 語言之外，有其他很多語言也支持 printf() 風格的格式化，例如 Java、Perl、Ruby 等等 (http://en.wikipedia.org/wiki/Printf#Programming_languages_with_printf)。學會 printf() 的格式化方法，這個知識還可以用到其他語言中。但是 C++ iostream 只此一家別無分店，反正都是格式化輸出，stdio 的投資回報率更高。
基于這點考慮，我認為不必深究 iostream 的格式化方法，只需要用好它最基本的類型安全輸出即可。在真的需要格式化的場合，可以考慮 snprintf() 打印到棧上緩沖，再用 ostream 輸出。
5. 線程安全與原子性
iostream 的另外一個問題是線程安全性。stdio 的函數是線程安全的，而且 C 語言還提供了 flockfile(3)/funlockfile(3) 之類的函數來明確控制 FILE* 的加鎖與解鎖。
iostream 在線程安全方面沒有保證，就算單個 operator<< 是線程安全的，也不能保證原子性。因為 cout << a << b; 是兩次函數調用，相當于 cout.operator<<(a).operator<<(b)。兩次調用中間可能會被打斷進行上下文切換，造成輸出內容不連續，插入了其他線程打印的字符。
而 fprintf(stdout, "%s %d", a, b); 是一次函數調用，而且是線程安全的，打印的內容不會受其他線程影響。
因此，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 在設計方面的缺點
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 的對象?？瓷先ビ悬c像 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 或“以某物實現”?！禖++ 編程規范》條款 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<num_put>(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 版本，在獲得便利性的同時避免付出不必要的代價。
一個 300 行的 memory buffer output stream
我認為以 operator<< 來輸出數據非常適合 logging，因此寫了一個簡單的 LogStream。代碼不到 300行，完全獨立于 iostream。
這個 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 <ostream>，降低了耦合。
class Date
{
public:
Date(int year, int month, int day)
: year_(year), month_(month), day_(day)
{
}
- void writeTo(std::ostream& os) const
+ template<typename OStream>
+ void writeTo(OStream& os) const
{
char buf[32];
snprintf(buf, sizeof buf, "%d-%02d-%02d", year_, month_, day_);
os << buf;
}
private:
int year_, month_, day_;
};
-std::ostream& operator<<(std::ostream& os, const Date& date)
+template<typename OStream>
+OStream& operator<<(OStream& os, const Date& date)
{
date.writeTo(os);
return os;
}
現實的 C++ 程序如何做文件 IO
舉兩個例子， Kyoto Cabinet 和 Google leveldb。
Google leveldb
Google leveldb 是一個高效的持久化 key-value db。
它定義了三個精簡的 interface：
接口函數如下
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#35 http://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，輕松做到線程安全。